How Large a Self-Contained HTML File Gets for a Typical Page

A typical self-contained HTML file is about 1.4 to 1.6 MB before JavaScript, and roughly 2 MB to 2.3 MB if the scripts are inlined too. Images cause almost all of that. No public dataset measures self-contained files directly, so this article builds the estimate from published page weight data and says where the arithmetic is ours.

What the numbers are built from

The source is the page weight chapter of the 2025 Web Almanac, which reports HTTP Archive size distributions per resource type, split by desktop and mobile. We did not capture or measure any files ourselves. We took the published medians, applied the Base64 overhead, and added them up. Every figure below is either quoted from that chapter or marked as derived.

Two limits matter. First, the Web Almanac reports each resource type's median separately, and medians are not additive. The sum of five medians is a ballpark, not the median of the sums. Second, the Almanac tables describe what a browser downloads. A self-contained file inlines what the page actually uses, which can be less (lazy images that never load) or more (images the saver fetched eagerly).

A self-contained file here means one .html file with its CSS, images and fonts embedded, so it opens with no other files beside it. If you want to make one, see exporting self-contained HTML from Chrome.

Per-type medians and percentiles

These are the 2025 Web Almanac response sizes in KB. The p50 column is the median.

For total page weight, the Almanac's median is 2,412 KB on desktop and 2,164 KB on mobile. Images alone are 1,058 KB and 911 KB of that, which is the single largest piece.

The HTML row is worth a look on its own. In an HTTP Archive snapshot from January 2013 to January 2014, web.dev reported a median of 13 KB for HTML. The 2025 median is about 33 to 35 KB. The markup alone has roughly tripled, and it is still the smallest slice of a self-contained file.

Base64 overhead: about a third larger

Images and fonts are binary. To sit inside an HTML file they have to be written as text, almost always as Base64 in a data: URL. The Wikipedia article on the data URI scheme puts the cost at approximately 33% larger than the original data. A 300 KB JPEG becomes about 400 KB of text.

Inlining does not shrink anything. It trades requests for bytes. The same article recommends Base64 data URIs only when the server supports HTTP compression or the embedded file is smaller than 1 KB. A file you email or save locally gets no help from server compression, so you pay the full third.

The format itself is not the ceiling. MDN notes that browsers are not required to support any particular maximum length, and that Chromium and Firefox limit data URLs to 512 MB while Safari (WebKit) limits them to 2048 MB. Firefox 97 raised its old 256 KB limit to 32 MB, and Firefox 136 raised it to 512 MB. A real page never gets near those numbers. The practical limits are file transfer, memory and how long an editor takes to open the thing.

A back-of-envelope estimate

Here is the arithmetic, using the 2025 medians above. The text parts (HTML, CSS) stay as they are. The binary parts (images, fonts) get multiplied by 4/3 for Base64. This is our derivation, not a measurement.

So the answer to the title is roughly 1.4 to 1.6 MB without scripts and 2.0 to 2.3 MB with them, for a page at the median on every axis. Treat it as a center of mass, not a prediction for your page.

The spread is wide. The 90th percentile for images is 6,856 KB on desktop and 6,288 KB on mobile. A page with that much image data, inlined as Base64, produces a file well past 8 MB from the images alone (6,856 x 4/3 is about 9,141 KB). On the other end, the 10th percentile image weight is only 56 to 74 KB, so a lean page can come in under 200 KB.

Where the bytes go

Look at the ratio, not the totals. On desktop, images and fonts are about 1,081 of 1,199 KB across the four non-script types, around 90%. Inline them and that share grows, because Base64 applies only to them. Markup and styles together are roughly 118 KB, under 10% of the file.

Two self-contained files can differ by an order of magnitude for this reason. A marketing page with five hero photos and a text-only documentation page have about the same HTML and CSS budget. The photos make the difference.

Scripts are the other swing factor. The median desktop page ships 708 KB of JavaScript. Whether a saved file includes it depends on how you capture the page. A browser save usually keeps the scripts. A capture meant for design work often does not need them. Saving a Safari web archive is another route, with its own size profile.

Keeping the file small

You can cut a self-contained file down without touching the design. Each tip follows from the numbers above.

• Resize images before inlining. Images are about 90% of the bytes. A photo shown at 800 px wide does not need a 3,000 px source.
• Use a compressed format. Re-encode photos as WebP or AVIF before they become Base64, since the 33% overhead scales with the starting size.
• Inline small assets only. The Wikipedia guidance of under 1 KB is a reasonable line for icons. Larger files are better left as separate assets if the format allows it.
• Drop scripts you do not need. At a 646 to 708 KB median, JavaScript is the second-largest block.
• Subset fonts. Fonts are small at the median (23 KB), but the 90th percentile is about 80 KB.

Does size predict import trouble

Size and import behavior are separate questions. UnHTML takes a self-contained .html file as input, and its pages state no file size limit. The free plugin caps imports at 500 layers per page, and Pro has no layer cap, as of October 2026. Layers come from elements, not bytes, so a 6 MB file of photos can import with fewer layers than a 300 KB file of dense markup.

Large files still take longer to load and open. If a page is slow to import, check the element count first, then the file size. For measured layer counts and fallback rates, see Figma import layer counts, fallback rates and font substitution data.

The short version

A median page saved as one file is about 1.4 to 1.6 MB without scripts and 2.0 to 2.3 MB with them, by our arithmetic from the 2025 Web Almanac. Images drive the number, Base64 adds about a third to every binary asset, and browsers will not stop you before 512 MB. If your file is far above that range, look at the images first. When you are ready to bring a saved page into Figma, start from the UnHTML homepage.