HTML Source Code & Formatting: The Complete Guide
A page's raw HTML source is the exact document a server sends before any JavaScript runs — a different, often much smaller thing than the live rendered DOM you see in browser DevTools after scripts have finished modifying the page. This guide covers why that gap matters for how crawlers actually see a page, the on-page SEO issues that only show up by reading the real source, and how formatting (beautifying) fits in without changing the markup itself.
Raw source vs. rendered DOM: not the same thing
Two different views of "the HTML" exist, and confusing them is the root of most misunderstandings about what a crawler sees:
- Raw source (View Source, or a direct HTTP fetch) — exactly what the server returned, before the browser has parsed it into a live document or executed a single line of JavaScript.
- Rendered DOM (Inspect Element / DevTools) — the current, live, in-memory state of the page after the browser has parsed the HTML and every script has finished running and potentially modifying it.
| Raw source | Rendered DOM | |
|---|---|---|
| How to see it | View Source / direct HTTP fetch | Inspect Element / DevTools |
| JavaScript executed? | No | Yes |
| What non-JS crawlers see | This, exactly | Not this |
| Reliable for checking meta tags, canonical, noindex? | Yes | No — may show post-JS state |
For a static, server-rendered page these are nearly identical. For a page whose content is built or substantially altered by client-side JavaScript — common in modern web apps — they can diverge enormously: text, links, and entire sections that are plainly visible in DevTools may not exist anywhere in the raw source at all.
Why this gap matters beyond curiosity
Google's own documentation confirms its crawler renders JavaScript in a second wave, queued separately from the initial crawl and more resource-constrained — meaning JS-dependent content can be indexed later than static content, sometimes significantly later. And Google is far from the only consumer of your HTML: many SEO tools, social-media link-preview crawlers, and a number of AI crawlers used by answer engines do not execute JavaScript at all. Content that exists only after client-side rendering is invisible to every one of them, permanently — not just delayed. This is exactly why checking the actual raw source, not just what looks right in a browser, catches problems that only show up for the crawlers and tools least forgiving about it.
The on-page issues that only show up in raw source
- Content that depends entirely on JavaScript to exist. If a title, key paragraph, or set of links only appears after a script runs, checking the rendered DOM alone will miss that they're absent from the plain HTML a non-JS-executing crawler receives.
- Duplicate or missing title/meta tags — easy to miss when skimming a rendered page, immediate to spot in the raw
<head>. - An incorrect or missing canonical tag, or one pointing at the wrong URL entirely — invisible unless you're reading the actual
<link rel="canonical">line. - A leftover noindex tag from a staging environment, silently keeping a live production page out of search results.
- Multiple H1 tags on one page — usually a template or CMS quirk that's easy to overlook visually but shows up immediately when scanning raw markup.
Formatting: cosmetic, and deliberately so
Minified production HTML is often delivered as a single, unreadable line — a legitimate, common performance optimization that strips whitespace to shave transfer size. Formatting (beautifying) it back into readable, indented markup changes nothing about how a browser or crawler interprets it: HTML whitespace between tags carries no semantic meaning, so reformatting is purely a readability transform, safe to run on any real markup before reviewing it. For example, this single-line source:
<div><h1>Hi</h1></div>reformats to:
<div>
<h1>
Hi
</h1>
</div>— identical markup, just laid out for a human to actually read it. Frost Rank's HTML Formatter & Source Checker does exactly this, alongside quick checks for the common on-page issues listed above, whether you paste HTML directly or fetch it from a live URL.
Frequently asked questions
View Source shows the HTML the server sent before any JavaScript ran; Inspect Element shows the live DOM after scripts changed it. On JavaScript-heavy sites the two can differ completely. See raw source and the rendered DOM compared.
Because Google renders JavaScript later in a separate, limited pass, and many SEO, social and AI crawlers never run JavaScript at all. Content that only exists after scripts run may be indexed late or never seen. See why the gap matters for crawlers.
No. Formatting only changes the whitespace between tags, which HTML ignores, so it's safe on any markup. See a before-and-after example.
Missing or duplicate titles and meta descriptions, a wrong canonical, multiple H1s, a leftover noindex, and content that only exists after JavaScript runs. See why each one hides in raw source.
It's been minified: build tools strip whitespace to make the file slightly smaller. A formatter puts the line breaks and indentation back. See how formatting restores it.
Yes — a server-side HTML fetcher (like Frost Rank's HTML Formatter & Source Checker) requests the URL directly and shows the exact raw response, routed through a server specifically because fetching another site's raw HTML from client-side JavaScript in your own browser is blocked by CORS for almost every real-world site.
The formatted-output example above was verified against the actual indent behavior of Frost Rank's own HTML Formatter — after an earlier version of that tool's own page shipped an example that didn't match its real output, every worked example on this site is now checked against real tool logic before publishing.
Was this guide helpful?
Rate it and leave a comment — takes 10 seconds, and genuinely helps decide what to fix or build next.