Free SEO Tool

Page Weight & Asset Size Checker

Measure your HTML and every asset on the page against Googlebot's 2 MB per-file crawl limit and Bing's HTML size guidance.

Why Page Weight Matters for Crawling

In February 2026, Google updated its crawler documentation with a number that had been folklore for years: Googlebot crawls only the first 2 MB of a supported file type (64 MB for PDFs). The limit applies per resource — your HTML document, each CSS file, and each JavaScript file are fetched separately, and every one of them is cut off at 2 MB of uncompressed data. Anything past that point is never fetched: content is invisible to Search, and a JavaScript bundle truncated mid-file can make Google misread the entire page.

Bing approaches the document itself with soft guidance rather than a hard cutoff. Bing Webmaster Tools shows a low-priority notice for HTML above roughly 125 KB — "risks not being fully cached" — and current Bing documentation references a 1 MB soft limit. Pages over those thresholds are routinely indexed; the notice is an early signal, not a penalty. For perspective, the median HTML page on the web weighs about 30–33 KB — most sites are nowhere near any of these numbers. The risk group is JavaScript-heavy single-page apps and "inline everything" builds: hydration state dumped into the document, critical CSS inlined wholesale, SVG sprites embedded in markup, and multi-megabyte vendor bundles.

Because the limits apply to uncompressed bytes, gzip or Brotli compression does not rescue an oversized file. A 5 MB bundle that travels as 1 MB on the wire is still truncated at 2 MB once decoded. This tool reports both numbers for every file so you can see exactly where you stand.

What Gets Measured

  • The HTML document — transferred and uncompressed size, checked against Google's hard 2 MB limit and Bing's soft 125 KB / 1 MB thresholds
  • JavaScript — script[src] tags and modulepreload hints
  • CSS — stylesheets and preloaded styles
  • Images — img tags, every unique srcset variant, picture sources, favicons, and url(...) references in inline styles
  • Fonts, media, iframes — preloaded fonts, video/audio sources and posters, embedded frames and objects
  • Inline data: URIs — counted toward page weight without being fetched

How to Use the Results

Fix red warnings first — any file over Google's hard limit is being truncated by Googlebot today. Amber notices are softer signals worth addressing on your own schedule, not emergencies. For oversized HTML, externalize inlined scripts, styles, and state into separate files (each gets its own 2 MB budget). For oversized JavaScript, code-split the bundle into smaller chunks. For images and media, compress and serve modern formats. Remember that the limits are about uncompressed size: minification and code removal shrink the real number, gzip alone does not.

Heavy JavaScript is also the root cause of most rendering and indexation problems. If your content only appears after a multi-megabyte bundle executes, pre-rendering serves bots fully rendered HTML so indexing never depends on the bundle being fetched and executed at all. Pair this tool with the Quick SEO Audit for a broader technical check, Core Web Vitals for the user-facing performance picture, and the Crawler Checker to see what each bot actually receives from your server.

The canonical reference is Google's Googlebot documentation, which describes the per-file crawl limits and truncation behavior.

Frequently Asked Questions

What is Google's 2 MB crawl limit and what happens above it?
In February 2026 Google documented that Googlebot crawls only the first 2 MB of a supported file type (64 MB for PDF). HTML, CSS, and JavaScript files are each fetched separately, and each fetch is bound by its own 2 MB limit. Anything beyond the first 2 MB of a file is simply not fetched — content past that point is invisible to Google Search, and a truncated HTML or JS file can cause Google to misread the page entirely.
Does the limit apply to compressed or uncompressed size?
Uncompressed. Google applies the 2 MB limit to the decoded data, so serving a 5 MB JavaScript bundle with gzip compression that brings it down to 1 MB on the wire does not help — Googlebot still stops processing at 2 MB of uncompressed content. This is why the tool reports both transferred (compressed) and uncompressed bytes, and evaluates warnings against the uncompressed number.
Does each JavaScript or CSS file get its own 2 MB limit?
Yes — the limit is per file, not per page. A page that loads ten 1.5 MB scripts is fully crawlable (though slow), while a page with a single 2.5 MB bundle has a problem: the bundle is truncated at 2 MB and any code beyond that point never executes during rendering. Code-splitting an oversized bundle into smaller chunks is a legitimate fix.
What is Bing's HTML size limit?
Strictly speaking, it is not a limit — it is soft guidance. Bing Webmaster Tools shows a low-priority notice ("Evaluated size of HTML is estimated to be over 125 KB and risks not being fully cached") for documents above 125 KB. Caching is not the same as indexing: pages well above 125 KB are routinely indexed by Bing, and current Bing documentation references a more generous 1 MB soft limit. For context, the median HTML page on the web is roughly 30–33 KB. This tool reports the Bing thresholds as yellow notices and reserves red warnings for Google's hard 2 MB cutoff, where content is genuinely truncated.
Do you store the URLs I check?
We do not persist URLs or response bodies. Requests are made server-side to fetch the target page and its assets, results are returned to your browser, and the data is not stored. Aggregated, anonymous usage counts are tracked via standard analytics for capacity planning only.
Why do some assets show "n/a" instead of a size?
The tool tries a HEAD request first, then a Range request, then a streaming download. An asset shows "n/a" when all of these fail — typically because the server refuses HEAD and Range requests and the download timed out, or the asset returned an error status like 403 or 404. Failed assets are listed with their HTTP status and excluded from the measured totals, so the rest of the report stays accurate.
Are assets referenced inside external CSS files counted?
Not yet. The tool scans the HTML document itself — scripts, stylesheets, images and srcset variants, fonts, media, iframes, preload hints, and url(...) references in inline styles. Fonts and background images referenced inside external stylesheets (@import or url(...) in a .css file) are not expanded in the current version. This is a documented limitation we plan to lift.
How accurate are the "estimated" sizes?
When a server only reports a compressed content-length for a small, non-text asset, the tool may use that as an estimate of the uncompressed size instead of re-downloading the file. Estimates are marked with a ≈ symbol in the table. For anything large enough to matter for the 2 MB limit — or any text-based file — the tool downloads and decodes the body to get the exact uncompressed size.