What is a code-to-text ratio?
It's the share of a web page's HTML that is readable text rather than markup. This checker downloads a page, deletes every <script> and <style> element, collapses runs of whitespace into single spaces, and divides the remaining text's size by the size of the original HTML. A page that's 15% text is 85% tags, attributes, scripts and styles.
The number is a rough proxy for how much of each response is content. It's useful for spotting two things: pages buried under markup, and pages with almost nothing to read.
The calculation
ratio = (bytes of text after stripping script/style and collapsing whitespace)
÷ (bytes of the full HTML response) × 100, rounded to one decimal
Both sides are measured in bytes, not characters. Plain English text is one byte per character in UTF-8, but accented Latin letters take two bytes and most Chinese, Japanese and Korean characters take three. A Japanese page can therefore show a higher ratio than an English page with the same amount of visible content.
The text side is everything the parser treats as a text node, after the removals:
- Counted as text: headings, paragraphs, link text, list items, table cells,
<noscript>content, and the<title>. - Counted as code: tags and all attribute values (including
alttext,hrefvalues and<meta>content), HTML comments, and of course scripts and stylesheets.
Two examples
A 1,024-byte product page (a title, meta and link tags in the head, a one-line inline style and script, then an <h1>, one paragraph and five links):
Code-to-text ratio: 16.4% (168 bytes of visible text out of 1024 total HTML bytes).
A single-page app whose server HTML is just a title, an empty <div id="app"> and a script tag:
Code-to-text ratio: 7% (9 bytes of visible text out of 129 total HTML bytes).
The 9 bytes in the second result are the word "Dashboard" from the <title>. Nothing in the body is text until JavaScript runs.
Does the ratio affect rankings?
Google's documentation doesn't describe any ratio of text to HTML as a ranking signal, and Google has published no ideal value. Be wary of any audit that marks a page as failing because it's below some percentage.
What the ratio can do is lead you to issues that matter for other reasons:
| Low ratio caused by | Why it matters | How to confirm |
|---|---|---|
| Large inline JSON state from a JS framework | Inflates every response; parsing costs on slow phones | Search the source for big <script> blocks, then check page size |
| Inline SVG icons repeated many times | Bloated HTML that can't be cached separately | Search the source for <svg> elements; move repeated icons to a sprite or image file |
| Client-side rendering with an empty shell | Crawlers that don't run JavaScript see nothing | Use the spider simulator |
| Genuinely little content | Thin pages may not satisfy searchers | Count the words with the word counter |
| Heavy navigation and footer markup | Mostly harmless; common on large sites | Compare with other pages using the same template |
On the JavaScript point, Google does render pages with a headless Chromium after crawling, but its JavaScript SEO basics page still recommends server-side or pre-rendering and notes that not all bots can run JavaScript.
Investigating a low ratio
- Run this checker on the page and on a similar page that performs well, so you have a baseline from the same template.
- View the source of the low page and find the largest non-text blocks.
- Decide whether each block needs to be inline. Scripts and stylesheets in external files are excluded from this measurement and can be cached by browsers.
- Strip comments and whitespace with the HTML minifier if your build doesn't already.
- Run the checker again. A rise is a side effect worth having only if the page also got smaller or faster; adding filler text to move the ratio helps nobody.
How the page is fetched
The URL you enter is sent to our server, which requests it with a user agent naming this site, follows up to ten redirects, and waits up to eight seconds for each response. It reads at most the first 2,000,000 bytes, so on an enormous page the ratio describes only that first part, and the result says so. Addresses in private or reserved IP ranges are refused, and an empty response is reported as "That page returned an empty response."
Last updated