What counts as a layer when UnHTML imports a page into Figma?

Every HTML element that survives the import becomes a Figma node: frames for containers, text nodes for copy, vector nodes for icons and simple graphics, and image fills for raster assets. A page's layer count tracks closely with its DOM element count, since UnHTML maps structure one to one rather than flattening it into a single rasterized frame.

Will my page exceed UnHTML's free tier 500 layer cap?

It depends heavily on how the page is built. Public DOM size data puts the median mobile page at roughly 594 elements, already past 500, with a quarter of pages over 1,000. A lean, semantic marketing page can land well under the cap; a div heavy page built on a page builder is more likely to exceed it.

Which fonts are most likely to get substituted on import?

Self hosted, non Google fonts delivered as WOFF2, the dominant web font format, are the most exposed, because Figma only installs local fonts in TTF or OTF. Google Fonts, used on roughly half of all pages, are fetched on demand inside Figma and essentially never substitute.

What does Figma substitute a missing font with?

Inside the import report, UnHTML falls back to Inter when no installed or Google Font match is found for a text node. At the glyph level, Figma's own renderer has a separate, narrower fallback: unsupported characters resolve to a Noto family font, consistently across macOS, Windows and web, rather than chaining through the various fallback fonts a browser would use.

Does a complex layout always fail to become Figma auto layout?

No. Flexbox and Grid are supported by roughly 98% and 97.5% of browsers in use, so browser support is not the obstacle. What determines whether a section maps cleanly to auto layout is how specifically its CSS was authored. Sections with clean flex or grid rules convert; deeply nested or absolutely positioned sections are more likely to fall back to fixed positioning.

Figma Import Layer Counts, Fallback Rates, and Font Substitution Data

Public DOM and font usage data show how many layers a marketing page imports as, where the 500 layer free tier line falls, and which fonts substitute.

DATASETDESIGNERPublished 4 October 2026

Open an import's layer panel and three numbers tell you most of what you need to know: how many layers you got, how many sections fell back to fixed position instead of auto layout, and how many fonts got swapped. None of that is random. All three trace back to how the original page's HTML, CSS, and fonts were built, and public measurement data on millions of live pages already shows the pattern.

The capture method matters here, so here it is up front. Layer count figures below come from the HTTP Archive's 2024 Web Almanac, which crawls the DOM of millions of live pages twice a year. Font figures come from the 2025 Web Almanac's font chapter, the same project's typography crawl. Both are public, dated datasets. That's a more honest way to answer "what does a typical import look like" than running UnHTML against a small batch of pages and calling it representative.

How many layers a marketing page actually imports as

UnHTML maps a page's structure one to one: a div becomes a frame, a text node becomes a text layer, an image becomes an image fill. Nothing gets flattened or merged along the way, so the layer count an import ends with tracks closely with the page's DOM element count.

The distribution is wider than most people expect. Across the 2024 Web Almanac's percentile breakdown for mobile pages, the 10th percentile page has 180 elements. The 25th has 342. The median sits at 594. The 75th reaches 1,010, and the 90th hits 1,716. The median has dropped slightly, from 653 in 2022 to 594 in 2024, but the top quarter of pages is still well above a thousand elements.

Where those elements come from matters too. Divs alone account for 28.7% of every element on an average page, with anchor tags at 12.6% and spans at 11.2%. Add in list items at 7.7% and most of a typical layer count is generic containers and links, not meaningful content nodes. A page built with deeply nested wrapper divs will out layer a page with the same visible content built on semantic, flatter markup, every time.

That distribution lines up directly with UnHTML's free tier, which caps at 500 layers and uses absolute positioning rather than auto layout. A page at the 25th percentile, 342 elements, clears that cap comfortably. The median page, 594 elements, is already over it. A page at the 75th percentile, 1,010 elements, is more than double the limit. Lighthouse's own DOM size audit warns starting at 800 nodes and fails outright above 1,400. So the page already flagged for DOM bloat in PageSpeed Insights is, on the same measurement, the page most likely to need Pro's uncapped auto layout conversion rather than the free tier.

Font substitution: who is exposed and who is not

Font substitution isn't evenly distributed across the web either. The 2025 Web Almanac's font chapter puts web font usage at 88% of all pages, up slightly from 87% in 2024. The remaining 12% rely on system fonts and never face a substitution question at all.

Among the 88% that do use a custom font, hosting is the dividing line. 72% self host at least one font file, while Google Fonts alone appear on 54% of desktop pages and 47% of mobile pages. Figma fetches any Google Font on demand, with no local install required, so that roughly half of all font usage essentially never triggers a substitution. The exposure concentrates in the self hosted, non Google slice.

Format adds another filter, and it catches more pages than hosting choice alone would suggest. 65.2% of font requests on the web ship as WOFF2, the dominant modern format. But as of 2026, Figma's local font install only reads TTF and OTF files. A self hosted font licensed correctly and sitting on the page in WOFF2 still substitutes on import, unless that exact family also exists on your machine as a TTF or OTF. Having the right font isn't the same as having it in a format Figma can see.

Variable fonts add a narrower failure mode. 39.4% of desktop pages and 41.3% of mobile pages now use a variable font. If the installed file is missing a single static style, commonly Bold, only that one style substitutes while the rest of the family imports correctly. The result looks odd the first time you see it in a report: one family, partly correct, partly swapped.

What a fallback actually looks like once it lands

Two different kinds of fallback show up in an import, and they come from different places. The first is layout: a section that can't map cleanly to Figma's auto layout falls back to absolute, fixed positioning. The second is font: a text node UnHTML can't resolve against an installed font or a Google Font falls back to Inter, logged in the import report.

The layout fallback isn't a browser compatibility problem. Flexbox support reaches 98% of browsers in active use, and Grid support sits at 97.5%, effectively universal on both specs. When a section still falls back to absolute position on import, the cause is how specifically that section's CSS was authored: deeply nested wrappers, mixed positioning contexts, or layout driven by JavaScript rather than CSS rules UnHTML can read statically. Not a missing feature in the browser rendering it.

Figma has its own separate fallback, one level below the font swaps UnHTML logs. According to Figma's own engineering blog, when a character has no glyph in the active font, Figma resolves that single character to the Noto font family, consistently across macOS, Windows, and the web, rather than chaining through the platform specific fallback fonts a browser would use. That's a narrower, character level fallback inside Figma's renderer, separate from the family level substitution an import report tracks.

Reading your own import report

The report an import generates is the fastest way to turn these averages into a specific answer for a specific page. Three things are worth checking, in order: the total layer count against the 500 layer free tier line, the list of substituted font families against what's actually installed locally, and any section flagged as a fallback to fixed position if you plan to restyle it later.

Here's a practical path through a report with several substitutions. Scan the list first. Then decide, per family, whether it's worth installing the real font locally as a TTF or OTF and re running the import, or accepting Inter because the file is a quick mockup rather than a pixel for pixel rebuild of the typography. UnHTML surfaces this report automatically on every import, in line with its own privacy policy of resolving everything locally.

What the numbers add up to

Layer counts, fallback rates, and font substitution all trace back to the same root cause: how a specific page's markup, CSS, and fonts were authored. A lean, semantic page with Google Fonts and clean flex or grid rules will clear the free tier and come through with its typography intact. A div heavy page built on self hosted WOFF2 fonts with absolutely positioned sections will hit the layer cap, substitute several fonts, and need a second pass on layout.

None of that is visible before you import. It's visible the moment you open the report.

Questions

What counts as a layer when UnHTML imports a page into Figma?: Every HTML element that survives the import becomes a Figma node: frames for containers, text nodes for copy, vector nodes for icons and simple graphics, and image fills for raster assets. A page's layer count tracks closely with its DOM element count, since UnHTML maps structure one to one rather than flattening it into a single rasterized frame.
Will my page exceed UnHTML's free tier 500 layer cap?: It depends heavily on how the page is built. Public DOM size data puts the median mobile page at roughly 594 elements, already past 500, with a quarter of pages over 1,000. A lean, semantic marketing page can land well under the cap; a div heavy page built on a page builder is more likely to exceed it.
Which fonts are most likely to get substituted on import?: Self hosted, non Google fonts delivered as WOFF2, the dominant web font format, are the most exposed, because Figma only installs local fonts in TTF or OTF. Google Fonts, used on roughly half of all pages, are fetched on demand inside Figma and essentially never substitute.
What does Figma substitute a missing font with?: Inside the import report, UnHTML falls back to Inter when no installed or Google Font match is found for a text node. At the glyph level, Figma's own renderer has a separate, narrower fallback: unsupported characters resolve to a Noto family font, consistently across macOS, Windows and web, rather than chaining through the various fallback fonts a browser would use.
Does a complex layout always fail to become Figma auto layout?: No. Flexbox and Grid are supported by roughly 98% and 97.5% of browsers in use, so browser support is not the obstacle. What determines whether a section maps cleanly to auto layout is how specifically its CSS was authored. Sections with clean flex or grid rules convert; deeply nested or absolutely positioned sections are more likely to fall back to fixed positioning.