Skip to content
Lizely

HTML Page Weight Analyzer

Measure the UTF-8 byte weight of pasted HTML, separate inline code and embedded data from external references, and compare the response body with Googlebot's current 2 MB fetch boundary without pretending to fetch the live page.

Privacy: your files never leave your device. All processing happens locally in your browser.

How to use

  1. 1.Paste the original uncompressed HTML response body, preferably from View Source or an authorized curl capture rather than a mutated Elements panel.
  2. 2.Run the analysis and review total UTF-8 bytes, the 2 MB reference, inline script/style shares, data URI weight, and the bounded external-resource inventory.
  3. 3.Fix the largest source-level hotspot, then remeasure the deployed response and remember that HTTP headers and separately fetched resources are outside this pasted-body calculation.

About HTML Page Weight Analyzer

HTML Page Weight Analyzer measures the source you paste instead of estimating a live URL. It reports the exact UTF-8 byte length of that text, its Unicode code-point count, the share occupied by inline script and style content, embedded data URI bytes, and a bounded inventory of external resource references. Everything runs in the browser. The HTML is not uploaded, fetched as a page, or executed.

Byte size is different from JavaScript string length. A browser string counts UTF-16 code units, while an HTML response is normally transferred as encoded bytes. ASCII characters usually occupy one UTF-8 byte, but accented letters, CJK text and emoji occupy more. The analyzer uses the browser TextEncoder API so the headline total reflects UTF-8 bytes rather than a misleading character count.

The Googlebot comparison is a reference, not a certification. Google's current documentation says Googlebot crawls the first 2 MB of a supported file and stops fetching at the cutoff. Google also states that the limit applies to uncompressed data. A later technical explanation adds that HTTP headers consume part of the per-URL allowance. Because this tool receives only a pasted response body, it cannot know the size of the real response headers or prove exactly where Googlebot will stop.

For a transparent and conservative calculation, the interface labels 2 MB as a decimal 2,000,000-byte body reference. It shows remaining bytes below that reference or overage above it, while keeping the header caveat visible. Google notes that limits can change, so the source link and reference date matter more than treating the number as a timeless constant.

Linked resources do not add their payload bytes to the pasted HTML total. An external stylesheet, script, image, frame, preload or media reference contributes only the characters that appear in the HTML response. Googlebot and the Web Rendering Service may fetch referenced resources separately, with their own limits. The analyzer lists supported references so you can distinguish a heavy document from a document that merely points to heavy files, but it never downloads those files or claims to know their sizes.

Inline code does count toward the document body. The analyzer measures the text inside each inline script and style element as UTF-8 and reports both byte totals and percentages of the complete source. External script elements are listed by src instead. Stylesheet and preload links are identified through rel tokens; common direct image, media and frame attributes are inventoried. A srcset value is preserved as one declaration because data URLs make naive comma splitting unsafe. Counts and displayed values are bounded so a huge pasted document cannot create an unbounded result view.

Data URIs are part of the HTML source and can make a response unexpectedly large. The analyzer finds data: values in supported direct resource attributes, counts them, and measures the complete attribute value as it appears in the pasted source. It does not treat an arbitrary title or data-* attribute as a resource, and it does not decode Base64 and then add the decoded payload again, because that would double-count bytes already present in the HTML.

The parser uses a detached template fragment and the browser's native HTML tokenizer. That matters for textarea, title, script, style and other raw-text boundaries that a regular expression can misread. Nested template content remains inert and outside the resource inventory. Pasted script elements do not execute, forms do not submit, and image, iframe, stylesheet or script URLs are not requested. Results are rendered as text. A strict input limit, a shared element cap and bounded URL display protect the main thread and output from accidental full-site dumps or adversarial markup.

This is not a network waterfall, compression calculator or Core Web Vitals test. It does not know gzip or Brotli transfer size, server headers, cache behavior, late client-side DOM mutations, resource response sizes, execution cost, rendering cost or what Google actually indexed. Use browser DevTools or curl against the authorized public response when those facts matter.

Paste the original delivered HTML response whenever possible. Copying the Elements panel after JavaScript runs can include mutations that were not in the response and omit source details that were. View Source, a saved response body or an authorized curl capture is a better input for this measurement. If the server varies by user agent, locale, authentication or device, test the representative response separately.

Treat the breakdown as a debugging map. Large inline script bytes may point to serialized application state, duplicated hydration data or embedded libraries. Large inline style bytes may indicate repeated critical CSS. Large data URI totals can reveal Base64 images or fonts embedded directly in markup. A long external-resource inventory may reveal duplicate tags, though reference count alone is not a performance score.

After finding a hotspot, make the smallest truthful change and remeasure the real response. Move appropriate code to cacheable external files, remove duplicated serialized data, avoid embedding large binary payloads in data URIs, and place critical metadata and content early in the response. Then verify the deployed bytes, response headers, rendered page and indexing evidence rather than assuming a smaller number guarantees crawling, indexing or ranking.

Methodology & sources

The analyzer measures the original input with TextEncoder UTF-8 bytes, parses a detached template fragment without attaching it to the live document, classifies inline script/style text and common resource attributes, counts data URI attribute values once, and bounds extraction and display. The 2,000,000-byte body comparison is explicitly labeled as a conservative decimal reference to Google's current 2 MB per-URL Googlebot limit; HTTP headers, compression, external payloads and indexing outcomes remain outside the result.

Frequently asked questions

Does this tool fetch my URL or load resources from the pasted HTML?
No. It parses the pasted text inside a detached template fragment and does not request, execute, upload or submit anything from that markup.
Does being below 2,000,000 pasted bytes guarantee Googlebot receives the whole page?
No. Google's current 2 MB allowance includes HTTP headers, while this tool sees only the body. The result is a transparent body reference, not a crawl or indexing guarantee.
Are external image, CSS and JavaScript file sizes included?
Only their URL text and tags are part of the HTML byte total. The external files are listed but never downloaded; Google fetches referenced resources separately.

Related tools

SEO & Webmaster guides

View all