Free Token Counter for Web Pages

A page is counted in tokens, and not all of them belong to the article.

Most token counters answer one question: how many tokens is this text? A page owner has two more. How much of my page is the article and how much is the template around it, and does each section hold up when an assistant lifts it out on its own?

What is a token in AI?

A token is the unit a language model reads and writes. Before a model sees any text, a tokenizer cuts it into pieces drawn from a fixed vocabulary: whole common words, fragments of rarer words, punctuation, digits, and the spaces in front of words. The model never sees letters or words as such; it sees a sequence of token numbers. Context windows, rate limits and API bills are all measured in these pieces, which is why a word count is the wrong unit for any of them.

Tokens are not words, and the gap is widest exactly where regulated firms write. Run through OpenAI's current tokenizer, “Depreciation recapture is the part of a gain taxed when you sell.” is 16 tokens for 12 words: depreciation alone becomes Dep reci ation, and recapture becomes rec apture. Numbers split hardest: 1031 is two tokens, $150,000 is four, and a year such as 2025 comes out as 202 and 5. Names, acronyms, code and non-English text cost more tokens per word than plain English prose does.

So there's no honest fixed ratio of words to tokens. Two of the pages checked with this tool on 29 September 2026 show the spread: Willowdale Equity's home page article came out at 2,060 words and 2,733 tokens, 1.33 tokens per word, while Verand's own home page, dense with product labels and figures, ran at 1.52. The card prints the ratio for the text you give it, measured, rather than a rule of thumb.

OpenAI tokenizer: o200k_base and cl100k_base

OpenAI publishes its tokenizers, which is what makes an exact count possible outside its servers. Its own library is called tiktoken; this page uses gpt-tokenizer, a JavaScript port of the same encodings that runs entirely in your browser, pinned to one version and loaded with an integrity hash so the file can't change underneath the page. Two encodings matter today:

The names describe the vocabulary: roughly 200,000 pieces against roughly 100,000. A larger vocabulary holds more whole words, so the same text usually comes out slightly shorter on o200k_base. On Willowdale's home page the article was 2,733 tokens on o200k_base and 2,775 on cl100k_base. For English prose the two stay close; for other languages the difference can be larger, which is one reason the card lets you switch.

The count is exact for the text under that encoding. It is not quite what a chat request is billed, because the API wraps each message in a few formatting tokens of its own, and a request also carries its instructions and the model's reply. For sizing a page, the text count is the number that matters.

Why there's no Claude or Gemini number here

Anthropic and Google don't publish tokenizers you can run locally for their current models. Anthropic offers a free counting endpoint in its API instead, and its documentation calls the result an estimate that can differ by a small amount from what a message actually uses. The same documentation says Claude Opus 4.7 and later models use a newer tokenizer that produces approximately 30 percent more tokens for the same input than earlier models, and tells developers to recount rather than reuse old figures. Google's API has a token-counting call of its own.

That rules out the shortcut some counters take, which is to run an OpenAI tokenizer and print the result under a Claude label, sometimes with an accuracy range attached. No published source supports a fixed conversion, and a single ratio would be wrong for one Claude generation or the other. So this card shows the counts it can compute exactly and says plainly which ones it can't.

Page Token Inspector: the article versus the chrome

Paste-in counters count whatever you paste. A web page is harder, because what a visitor reads as “the article” sits inside a template: navigation, a header, cookie banners, related-post rails, a newsletter form, a footer with legal disclosures and a link to every section of the site. All of it is text, and all of it is tokens.

The card separates the two with the rule Verand's site audit uses on every page it crawls. It takes the page's first <article> element if it holds real text, otherwise <main>, otherwise the body with its header, nav, footer and aside removed, and drops scripts, forms and embedded frames. That's the article. Separately, it keeps every visible word of the served page. Both are counted with the same tokenizer, and the bar on the card shows what share of the page's tokens is the article.

The two pages we checked sit at opposite ends. Willowdale's home page is 91 percent article: 2,733 of its 2,997 tokens. Verand's own home page is 22 percent: 3,657 of 16,686. The second number is also a lesson in reading the result. Verand's home page carries animated replicas of the product, and the first <article> element on the page is one of them, so the “article” counted there is a product view rather than the page's copy. When the share looks wrong, read the opening lines the card shows; they tell you which region was picked, and whether your template's markup points at the text you think it does.

Why it matters: an assistant that fetches your page and passes it to a model hands over text, and a template-heavy page spends tokens on menus and disclosures before it reaches the argument. How much of that a given assistant keeps isn't published, so no count predicts whether a page gets used. What the card gives you is the proportion, which is the part you control.

Does the page fit a context window?

A context window is the most text a model can take in at once, counted in tokens, and it has to hold the instructions, the question, any retrieved pages and the answer together. Window sizes change with almost every model release, so the card doesn't name models. It shows your article and your whole page against generic sizes, 8K, 32K, 128K, 200K and 1M tokens, and you check the model you care about against its own documentation.

A single article rarely troubles a modern window: Willowdale's home page is under 3,000 tokens. Where the question bites is combination. An assistant answering from several sources, a support bot grounded in your whole knowledge base, or you pasting five competitor pages into one prompt all add up fast, and a page that is four-fifths template fills the budget with the wrong text. The smaller windows still matter too, for the fast, cheap models that often do the retrieval and summarising in a larger system.

How the page splits into chunks

Systems that answer from documents rarely use a whole page. They split it into chunks, index those, and retrieve the few that match a question; that's the idea behind retrieval-augmented generation. Chunking strategies vary: fixed token lengths with some overlap, splits at structural boundaries such as headings and paragraphs, or splits where the meaning shifts. None of the major assistants publishes how it chunks the pages it reads.

So the chunk view on this card is labelled for what it is: an illustrative rule, not any engine's. It cuts the article wherever an H1, H2 or H3 starts, counts each section, and flags two cases. A section under 40 tokens, a heading with a line under it, has little to say if it's retrieved alone; link lists and calls to action often look like this and are fine where they are. A section over 800 tokens, roughly 600 words, probably covers more than one question, and any system that cuts it into smaller pieces will separate claims from the context that explains them. Willowdale's home page shows the second case: its “Investor questions, answered” section is 1,287 tokens, a whole FAQ under one heading, where each question under its own subheading would stand as its own passage.

The reason headings matter is quotability. When an assistant lifts a passage, the passage has to make sense without the paragraphs around it. A section that opens under a heading naming its question, answers it directly, and stays on that question is the easiest thing to quote accurately. The AI Content Readiness Checker grades a page on that directly; this card shows you the section sizes behind it.

An LLM token counter for pages, not just prompts

Most AI token counters, including the GPT tokenizer and ChatGPT tokenizer tools that fill search results, are built for prompts: paste text, get a number, sometimes a price. That covers the paste box here too, with the token visualizer on the card showing where each piece begins and ends. The URL mode is for the questions a site owner asks instead: how heavy is my template compared with my copy, how long is this guide in the unit a model reads, and which sections would a retrieval system have to cut. The Website Word Counter answers the same questions in words; tokens are the unit the model reads.

Common mistakes when counting tokens

• Multiplying words by a fixed ratio. Rules such as “a token is three quarters of a word” hold for some plain English and fail for figures, names, legal citations and other languages. Count the text.
• Using one model family's count for another. An OpenAI count is exact for OpenAI models and stands in for nothing else. Claude and Gemini count differently, and Claude's own count changed with its newer models.
• Counting the rendered page when you meant the article. Selecting everything on a page and pasting it into a counter includes the menus and the footer. The two numbers on the card are there to keep them apart.
• Treating page weight as tokens. A 2 MB page is not two million tokens. Markup, scripts and styles aren't text; the card counts only what a reader could read.
• Forgetting what else shares the window. Instructions, the question, other sources and the answer all draw on the same context window as your page.
• Reading a count as a verdict. A short page isn't penalised and a long one isn't rewarded. Token counts describe size; whether an assistant cites a page depends on far more than that.