Code to Text Ratio Checker

Paste only — this tool never fetches a URL.

Result

FREE TOOL · NO SIGN-UP

This code to text ratio checker shows how much of a web page is visible text and how much is HTML code. Paste the page source, click Analyze HTML, and you get the text-to-HTML ratio as a percentage with a Good, Average or Low rating. You also see the HTML size, text size, code size, word count, and how many script and style tags the page contains, plus quick tips if the markup looks bloated. The tool only reads what you paste; it never fetches a URL.

What the Code to Text Ratio Measures

The code to text ratio, also called the text to HTML ratio, compares the amount of visible text on a page with the total size of its HTML code. If a page’s source is 100 KB and the readable text inside it adds up to 15 KB, the ratio is 15%.

A low ratio means most of the page size is markup: tags, attributes, inline CSS, inline JavaScript, tracking scripts and template code. A high ratio means the page is mostly content.

The metric became popular in SEO audit tools as a quick health check. It can flag pages where code is crowding out content, such as thin content pages wrapped in a heavy theme, or templates bloated by page builders. Those pages tend to be slower and harder to maintain.

It is not a measure of content quality. A short page with a good answer can have a low ratio, and a long page of filler can have a high one. Treat it as a signal that points you toward pages worth a closer look, not as a score to optimize for its own sake.

How the Ratio Is Calculated

The checker reads your pasted HTML the way a browser would, using the browser’s own HTML parser. It then:

  1. Measures the full size of the HTML in bytes, using UTF-8 encoding.
  2. Removes elements that never show as readable text.
  3. Takes the remaining text content of the page body and collapses repeated whitespace.
  4. Measures that text in bytes.

The ratio is text bytes ÷ HTML bytes × 100. Code size is simply HTML size minus text size. Measuring bytes rather than characters keeps the comparison fair when a page uses non-English text or special symbols.

Elements counted as visible text

Visible text is the readable content inside the page body: headings, paragraphs, list items, table cells, link text, button labels, captions and similar elements. If a visitor could read it on screen, it is counted.

Some text that matters for SEO isn’t counted, because it lives in attributes or the head section rather than the body: the title tag, meta description, image alt text and link titles. That is normal; most ratio tools follow the same rule.

Text hidden with CSS but still in the HTML, such as collapsed accordions or tab panels, is counted, since it is part of the page’s text content.

Elements counted as code, including scripts and styles

Everything that isn’t visible text counts as code. That includes HTML tags and their attributes, comments, whitespace used for indentation, and the entire head section.

Before reading the text, the checker strips out elements whose contents are never displayed as text: <script>, <style>, <noscript>, <template>, <svg> and <iframe>. Their contents go to the code side of the ratio.

The tool also counts the script tags and style tags in your source. A high number of each, especially inline blocks, is often the main reason a ratio is low.

How to Check a Page in Three Steps

  1. Copy the page source. Open the page in your browser and press Ctrl+U (Cmd+Option+U on Mac) to view the source, then select all and copy. This gives you the HTML the server sends. For pages built mainly with JavaScript, open the browser’s developer tools instead, right-click the <html> element, and copy its outer HTML to get the rendered version.
  2. Paste and analyze. Paste the HTML into the “Page HTML source” box and click Analyze HTML.
  3. Read the results. The gauge shows the ratio and its rating. Below it, check the HTML size, text size, code size, words of text, and script and style tag counts. Tips appear when the ratio is low or there are many script tags.

You can paste the source of competitor pages too, to compare how much markup similar pages carry. The checker runs 100% in your browser, and the HTML you paste is never uploaded.

What a Good Text to HTML Ratio Looks Like

There is no official benchmark, but a common rule of thumb in SEO tools is 25% to 70%. This checker rates:

  • 25% and above: Good
  • 10% to 25%: Average
  • Below 10%: Low

Many real-world sites sit in the Average band. Modern themes, ecommerce templates and pages with navigation menus, footers and tracking scripts carry a lot of code, even when the content is strong.

Context matters more than the number. A long blog post should usually score higher than a product listing page, which is mostly images, filters and prices. Compare similar page types on your own site, and look for outliers: a template that is far lower than the rest is often the best place to start.

Is the Ratio a Ranking Factor?

Google has never listed the text to HTML ratio as a ranking factor, and its representatives have said they don’t use it. Search engines are good at separating code from content, so markup alone doesn’t push a page down.

The ratio still matters indirectly. Bloated code often means:

  • Slower load time. More bytes to download and parse can hurt page speed and Core Web Vitals, which are part of Google’s page experience signals.
  • Large DOM size. Deeply nested markup makes pages slower to render and update.
  • Thin content. A very low ratio can reveal pages with little useful text.
  • Crawl efficiency. Large pages take more resources to fetch, which can matter on very big sites.

So a low ratio is a symptom worth investigating, not a ranking problem by itself. Fix it if the cause is real bloat or thin content; ignore it if the page is simply light on text by design.

Ways to Reduce Bloated Code

If your ratio is low because of code rather than lack of content, a few changes make the biggest difference. Start with the template, since fixes there improve every page that uses it. Then look at plugins, page builders and third-party scripts that add markup to every request.

Moving inline CSS and JavaScript to external files

Inline <style> blocks and <script> code are repeated in the HTML of every page. Moving them into external stylesheets and script files means the browser downloads them once and caches them for later pages.

On WordPress, check for plugins and page builders that print large inline CSS blocks, and use their option to write styles to a file instead. Defer or delay non-essential scripts, and remove tracking or widget scripts you no longer use. A few critical styles can stay inline to speed up the first render.

Cutting comments, whitespace and unused markup

HTML comments, indentation and line breaks are useful while developing but add bytes in production. Minification removes them. You can use the HTML Minifier for markup and the CSS Minifier for stylesheets.

Also look for unused markup: hidden menus duplicated for mobile, empty wrapper divs, unused widgets, and large inline SVG icons that could be external files.

Misreadings and Mistakes to Avoid

  • Padding pages with text to raise the ratio. Adding filler makes content worse and doesn’t help rankings.
  • Comparing different page types. A category page and a long guide will never have similar ratios.
  • Treating it as a ranking score. It is an audit signal, nothing more.
  • Using the wrong source. View-source and the rendered DOM can differ a lot on JavaScript-heavy sites. Compare like with like.
  • Ignoring the template. Most code comes from the theme, not the article. Fixing the template fixes every page.
  • Stripping useful code. Structured data, accessibility attributes and essential scripts add bytes but add value too.
  • Forgetting compression. Gzip or Brotli shrink HTML a lot in transfer. The ratio measures raw size, not what actually travels over the network.

When the Ratio Does Not Matter

For pages that are naturally light on text, such as image galleries, video pages, web apps, tools, checkout pages and landing pages built around a form, a low ratio is expected. What matters there is speed, usability and whether the page does its job. If a page loads fast, passes Core Web Vitals and satisfies visitors, a low ratio is not something to fix.

Using the Ratio as One Audit Signal

Use the code to text ratio to spot outliers, then check speed and content quality before changing anything. Trim markup with the HTML Minifier, shrink stylesheets with the CSS Minifier, compress scripts with the JavaScript Minifier, and find more on the FHSEO Hub free SEO tools page.

Code to Text Ratio Checker FAQs

Many SEO tools treat 25% to 70% as a good text to HTML ratio, and this checker rates 25% or higher as Good. Many healthy sites score between 10% and 25% because of navigation and scripts. Compare similar page types on your own site rather than chasing a single target number.

Not directly. Google hasn’t named the code to text ratio as a ranking factor. It matters indirectly, because bloated code can slow pages down and hurt Core Web Vitals, and a very low ratio can reveal thin content. Use it as an audit signal that points you to pages worth checking.

Remove unnecessary code first. Move inline CSS and JavaScript to external files, minify HTML, delete unused scripts and widgets, and simplify bloated templates. Where pages are genuinely thin, add useful content that answers real questions. Don’t pad pages with filler text just to push the percentage higher.

Everything that isn’t visible text counts as code: HTML tags and attributes, comments, indentation, the head section, and the contents of script, style, noscript, template, SVG and iframe elements. Text inside the page body, such as headings, paragraphs, lists and link text, counts as visible text in this checker.

Usually because of heavy templates, page builders, inline CSS and JavaScript, tracking scripts, or large inline SVG icons. Pages with little written content, such as product grids or galleries, are also naturally low. Check the script and style tag counts in the results to see whether code bloat or thin content is the cause.