Free tool Text to code ratio, and what the code actually is
Paste the HTML of a page and see what share of its bytes is text a visitor can read, and what the rest is: tags and attributes, inline JavaScript, inline CSS, comments, whitespace. There is no target percentage here, because Google has never published one. What the breakdown does show is where page weight hides.
- Ratio plus full breakdown
- Scripts, styles, SVG, data URIs
- Runs locally
Measure the text to code ratio
Paste the page source as the server sends it (View source → Select all → Copy). Sizes are UTF-8 bytes before compression, the same way Googlebot's size limit is measured.
A full page works best. Text inside <head>, <script>, <style>, <template> and <noscript> does not count as visible text.
Text to code ratio
26.1%
Visible text bytes ÷ total HTML bytes.
Visible text (bytes)
769
Body text with extra whitespace removed.
HTML size (bytes)
2,948
Uncompressed, UTF-8.
Words in visible text
141
Chinese characters count one each, other text by word.
What the HTML is made of
- Visible text26.1%
- Whitespace4.5%
- Tags and attributes49.9%
- Inline JavaScript9.1%
- Inline CSS8.1%
- Other (doctype, head text)2.3%
Breakdown
The first rows add up to the total. "Of which" rows are parts of tags and scripts shown separately.
| Part | Size | Share of HTML |
|---|---|---|
| Visible text | 769 B | 26.1% |
| Whitespace | 134 B | 4.5% |
| Tags and attributes | 1.4 KB | 49.9% |
| Inline JavaScript | 268 B | 9.1% |
| Inline CSS | 238 B | 8.1% |
| Other (doctype, head text) | 69 B | 2.3% |
| Of which: onclick and other handlers | 10 B | 0.3% |
| Of which: JSON-LD | 148 B | 5.0% |
Notes
Facts about this page, not pass or fail.
- NoteVisible text is 26.1% of this HTML (769 B of 2.9 KB). Google publishes no target for this number; use it to compare versions of the same page or similar templates.
- OKThe HTML is 2.9 KB, 0.1% of the 2 MB Googlebot fetches for Google Search. Size limit: fine.
- NoteStructured data (JSON-LD) takes 148 B. It counts as code here, but it is useful code: it is how rich results are described.
Version v1.0Updated Update history
Why there is no "good" ratio on this page
Text to code ratio became popular as an SEO metric, often with a claimed target such as "above 15%". Google's documentation contains no such threshold, and the number depends mostly on the template rather than on the content. It is still a useful lens if you read it as a breakdown.
The ratio itself
A product page with a big menu and a short description will score low; a long article with a plain template will score high. Compare the same page over time, or pages built on the same template, not one site against another.
Inline JavaScript and CSS
The parts most worth acting on. Code inside the HTML is downloaded again with every page view, while external files are cached. Large inline blocks usually come from page builders, tag managers or frameworks inlining state.
Data URIs and inline SVG
Images and icons embedded as text. Handy for a few small icons, expensive when a large photo or the same icon set is copied into every page.
Googlebot's 2 MB limit
The one hard number. Googlebot fetches the first 2 MB of an HTML file for Search, measured uncompressed, and only that part is considered for indexing. Pages near it are almost always bloated by inline data.
Size limits are from Google's Googlebot documentation (2 MB for HTML in Google Search) and its crawler overview (15 MB default for Google's crawlers, smaller for some).
Find what is bloating a page
Works on any HTML: a live page, a template or a build output.
-
1
Copy the source
View source on the live page (Ctrl+U) and copy everything. For a JavaScript app, also try the rendered HTML from developer tools (Elements → right-click
<html>→ Copy outerHTML). -
2
Paste it in
The ratio, the size and the breakdown update straight away.
-
3
Look at the largest code part
Inline scripts, inline CSS, data URIs, SVG or plain markup. The notes say what each one usually means and what to try.
-
4
Compare after the change
Paste the new version. Compare like with like: the same page before and after, not your page against a competitor's.
Ratio = visible text bytes ÷ total HTML bytes
Everything is measured in UTF-8 bytes of the source as pasted, before gzip or Brotli. A Chinese character is 3 bytes in both the text and the total, so the ratio is comparable across languages.
- Visible text: text nodes outside
<head>,<script>,<style>,<template>,<noscript>and<title>; runs of whitespace collapse to one space. Entities such as&count as written - Whitespace: the extra spaces, tabs and line breaks removed from text, plus whitespace-only text between tags
- Tags and attributes: everything from
<to>, including attribute values. Image alt text is markup here, not visible text - "Of which" rows (data URIs, inline SVG, style attributes, event handlers, JSON-LD) are already inside tags or scripts, so they are not added to the total again
| Source | Counted as | Bytes |
|---|---|---|
<p class="lead"> | Tags and attributes | 16 |
| Hello world (two spaces) | Visible text 11 + whitespace 1 | 12 |
| & | Visible text, as written | 5 |
<script>track()</script> | Tags 17 + inline JavaScript 7 | 24 |
| 中文 | Visible text | 6 |
The example blog post, measured
The default HTML is a short store blog post with an inline stylesheet, a JSON-LD block and a small inline script.
| Part | Bytes | Share |
|---|---|---|
| Visible text | 769 | 26.1% |
| Tags and attributes | 1,470 | 49.9% |
| Inline JavaScript (incl. 148 B of JSON-LD) | 268 | 9.1% |
| Inline CSS | 238 | 8.1% |
| Whitespace | 134 | 4.5% |
| Other (doctype, title) | 69 | 2.3% |
Ratio: 769 ÷ 2,948 = 26.1%, with 141 words of visible text. Half the file is markup, which is normal for a short post inside a site template. Try the "single-page app shell" example to see a page whose source has no visible text at all.
How the ratio gets misread
Most mistakes come from treating a descriptive number as a ranking factor.
Chasing a target percentage
Adding filler text to raise the ratio makes the page worse for readers and does nothing Google has documented. Remove code weight instead, if there is any to remove.
Comparing different templates
An e-commerce category page and a blog post will never have similar ratios. Compare a page with its own earlier version or with pages on the same template.
Measuring only the JavaScript shell
For React, Vue or other client-rendered sites, view-source shows an almost empty shell. Measure the rendered HTML too, and check that the content appears without user interaction.
Confusing HTML size with page speed
The HTML is one request among many. Images, external scripts and fonts usually weigh more; real-user Core Web Vitals tell you whether the page is actually slow.
From page weight to what visitors feel
The breakdown shows what a page is made of. TapCub shows how fast it loads for real visitors and whether they stay.
Core Web Vitals by page
LCP, INP and CLS at p75 from real visitors, slowest pages and templates first.
Learn morePage reports
Bounce and exit rate per page, so you can see whether a heavy page actually loses people.
Learn moreA small tracking script
TapCub's own snippet is about 2 KB and loads asynchronously, so it adds little to the pages you are trimming.
Learn moreText to code ratio questions
Still have a question?
Chat with the team behind TapCub — we usually reply within a few hours on business days.
What is the text to code ratio?
The share of a page's HTML that is visible text. This tool divides the bytes of visible body text by the total bytes of the HTML. The example page is 769 bytes of text in 2,948 bytes of HTML, a ratio of 26.1%.
What is a good text to code ratio?
There is no published standard. Figures like "above 15%" or "25–70%" come from SEO tools, not from Google, whose documentation does not mention the metric. Use the ratio to compare versions of the same page, and use the breakdown to find inline code you can move out.
Does text to code ratio affect SEO?
Not as a documented ranking factor. What Google does document is a size limit: Googlebot reads the first 2 MB of an HTML file for Search. Bloated HTML can also slow pages down, which shows up in Core Web Vitals.
How do I improve the ratio?
Move large inline scripts and styles into cached external files, stop embedding images as base64 data URIs, reference repeated SVG icons from a sprite, strip comments and minify the HTML. The code minifier shows the before and after size.
Why is the ratio 0% for my React or Vue site?
The server sends an empty shell and JavaScript builds the page in the browser. Copy the rendered HTML from developer tools to measure what visitors see, and make sure important content does not depend on clicks or scrolling to appear.
Does it count compressed or uncompressed size?
Uncompressed UTF-8 bytes of what you paste, which is also how Google measures its crawl size limit. Gzip or Brotli usually cut the transfer size several times over, markup and whitespace compressing especially well.
Is my HTML uploaded?
No. Parsing and counting happen in your browser; nothing is sent to TapCub or stored.
Update history
New features, fixes and data refreshes for this tool, newest first.
-
· v1.0
LaunchedFirst release.
Missing something or found an error? Tell us — requests that come up often go into the next update. All tool updates
Measure what visitors actually wait for
HTML size is one input. Add TapCub to see real-user load times and Core Web Vitals for every page.