The HTML Weight Analyzer does not fetch your URL and does not load any resources referenced in the pasted HTML — it only measures the bytes of the text you hand it, entirely inside your browser. Every measurement you see comes from parsing the literal string you paste, not from contacting the server that originally served that page. The analyzer never resolves the URLs that appear inside the markup, never opens a stylesheet, script, image, iframe, font, or media link, and never sends a request to a third-party domain just because the HTML mentions one. Inline JavaScript is read as text, not run; data URIs are scanned but never fetched; and even form actions are inert because the document is never submitted. The whole pipeline runs on your device in a detached template fragment that is not attached to the live page tree, so nothing inside the pasted HTML is rendered, executed, or transmitted. That is the design — a local byte counter for source-level HTML, not a crawler, a renderer, or a network tool.
That design directly answers the question behind searches like "does html page weight html page size analyzer fetch my url or load resources from the pasted html." If you pasted markup that contains staging URLs, admin paths, internal CDN hosts, or third-party trackers, the analyzer still does not contact any of them. It sees a string of bytes; nothing more.
What "Fetching a URL" and "Loading Resources" Actually Mean
In the SEO and browser world, "fetching a URL" means issuing an HTTP request to a server and reading the response. "Loading a resource" means letting the browser follow a src, href, srcset, or data URI in the markup and pull the bytes that come back — a stylesheet, a script, an image, a video, a font, an iframe, a preload, or a worker. Both behaviors originate from the browser engine, the DevTools panel, or a crawler such as Googlebot, and both leave traces in network logs.
The HTML Weight Analyzer does neither. You paste the response body you already captured, and the tool works on that string only. There is no entry field for a URL the tool will visit, no proxy that opens the page on your behalf, and no headless browser that renders your markup. If a stylesheet sits in the document, only the characters of its <link> tag contribute to the byte total; the bytes of the file itself stay on the file's server. The same rule holds for <script src>, <img src>, <source srcset>, <iframe src>, <video poster>, <link rel="preload">, and inline data: URIs — the analyzer reads the attribute text, never the resource.
This boundary matters for two practical reasons. First, your HTML may contain private URLs — admin paths, staging hosts, internal CDNs — that you do not want a third party to probe. Because nothing is fetched, pasting such markup is safe. Second, a heavy page is not always a heavy document; it can simply point at heavy external files. Separating the two is exactly the analyzer's job.
How the Analyzer Handles Pasted HTML Internally
The analyzer runs entirely client-side and follows a strict, bounded pipeline. Your pasted text is read into memory as a JavaScript string. That string is encoded into UTF-8 bytes using the browser's TextEncoder API, which gives the true wire-style byte count instead of a UTF-16 code-unit length. Per MDN, TextEncoder.prototype.encode() returns a Uint8Array containing the text encoded as UTF-8, which is what an HTML response is transferred as on the wire. That distinction matters because a JavaScript string count treats each UTF-16 code unit as one unit, while ASCII characters usually occupy one UTF-8 byte and accented letters, CJK text, and emoji occupy more.
The string is then parsed inside a detached <template> element. A template content fragment is inert by spec — its children are not fetched, executed, or rendered, and nested template content stays inert recursively. The browser's native HTML tokenizer walks the fragment, so raw-text boundaries in <textarea>, <title>, <script>, and <style> are read correctly rather than miscounted by a brittle regex.
From there, the analyzer classifies content without contacting anything. Inline <script> and <style> text is measured as UTF-8 bytes; external script src attributes, <link rel="stylesheet"> and rel="preload" hrefs, and direct image, media, and frame attributes are listed but never downloaded. data: URIs in supported attributes are counted once and measured at their raw attribute length, never decoded into a phantom payload on top of the original bytes. Results render as plain text inside a bounded output area, with a strict input cap, a shared element cap, and bounded URL display so a multi-megabyte paste cannot stall the page or run away.
Because the fragment is detached, it never becomes part of the live document. The browser cannot auto-load anything from a fragment that is not attached, and there is no <img> or <link> element appended to the real DOM. The <script> tags inside the fragment are inert — they are parsed, their text is measured, and then they sit in the fragment doing nothing. The same is true of inline event handlers, onerror, onload, and any URL they might reference. That is also why the analyzer can be used on third-party HTML samples, scraped snippets, or HTML copied from staging environments without leaking access to those hosts. The tool sees text. It does not see a server.
Run a Local Weight Check on Pasted HTML
- Capture the original uncompressed HTML response body — for example, the View Source output from your browser, or the response body from an authorized curl capture. Avoid the Elements panel after JavaScript has run, because mutations made by scripts do not belong in the source measurement.
- Open the HTML Page Weight Analyzer and paste that response body into the input area. No URL field is needed because the tool never visits one.
- Run the analysis. The interface reports the total UTF-8 bytes, the Unicode code-point count, the share of bytes inside inline scripts and styles, the byte weight of data: URIs, and a bounded inventory of external resource references (image, stylesheet, script, preload, frame, media) along with their attribute text.
- Compare the byte total against the 2,000,000-byte body reference on screen. The label makes clear that this is the analyzer's body-only measurement against Google's documented 2 MB per-URL allowance, not a guarantee that Googlebot received the entire page. For context on that limit, see Google's Inside Googlebot update.
- Identify the largest source-level hotspot from the breakdown — typically inline script bytes, inline style bytes, or a data URI block — and apply the smallest truthful change to the deployed response. Move serialized hydration data into cacheable external files, remove duplicated JSON, stop embedding large Base64 images in markup, and keep critical metadata early in the document.
- Remeasure the deployed response and verify the result with curl or DevTools. HTTP headers, compression, and separately fetched resources remain outside the pasted-body calculation, so confirm them separately when they matter.
What the Analyzer Reports vs. What Stays Outside
The analyzer answers a narrow question — how heavy is the source you captured — and the table below maps each common measurement to whether the tool covers it and why. Items marked "No" still matter to SEO, but they require a different instrument.
| Measurement | Reported by the analyzer | Why |
|---|---|---|
| UTF-8 byte length of pasted HTML | Yes | Encoded directly from the pasted string via TextEncoder |
| Unicode code-point count | Yes | Distinct from bytes; emoji and CJK glyphs occupy more than one byte each |
| Inline script and style byte totals and percentages | Yes | Measured as UTF-8 text inside raw-text boundaries |
| External script src, link rel="stylesheet", rel="preload" hrefs | Listed only | Only the attribute text counts toward bytes; the referenced files are never downloaded |
| img src, source srcset, iframe src, media attributes | Listed only | Only the attribute text counts toward bytes; the referenced files are never downloaded |
| data: URIs in supported attributes | Counted once | Measured at full attribute length; never decoded a second time on top of source bytes |
| HTTP response headers | No | They are not part of the pasted body |
| Gzip or Brotli transfer size | No | Compression is a transport property, not a source property |
| Bytes of referenced external files | No | External files are listed but never downloaded; Google fetches them separately |
| Rendered DOM after JavaScript runs | No | The fragment is inert and never attached to the live document |
| Execution cost, layout cost, Core Web Vitals | No | Out of scope for a source-level byte counter |
For a closer look at how external resource references are inventoried without their payloads, see the guide on HTML page weight and external file sizes.
When You Actually Need a Live Fetch or Network Waterfall
Some SEO questions require answers the analyzer cannot give, and you should reach for the right tool instead of misreading the byte total. If you need to see compressed transfer size, response headers, cache headers, redirect chains, or the timing of each request, capture the live response with curl or use the browser DevTools Network panel. For example, an authorized curl -I call gives the headers; a curl --output - --compressed capture gives the decompressed body that you can paste back into the analyzer for a real source measurement. If the server varies the response by user agent, locale, authentication, or device, run each variant separately so the breakdown reflects the representative response.
If you need to see what the page looks like after JavaScript runs, use a headless renderer or DevTools. The analyzer is not a renderer, and it does not model hydration cost, layout shifts, or time-to-interactive. Inline <script> bytes are reported, but the runtime work those bytes describe is not measured here. If you need to confirm indexing, look at Search Console, server logs, and a site: query — the analyzer cannot tell you whether Google fetched or kept a given response.
A useful pattern is to pair the analyzer with a sitemap audit when you suspect templates. Pull every URL from your XML sitemap in your browser with the sitemap URL extraction workflow, capture a representative response per template, and paste each one through the analyzer to see which template ships the most inline bytes. The breakdown then becomes a debugging map for the page rather than a guess about the site, and you keep the safety property intact: every paste stays local, and no URL inside the markup is ever fetched.