LLM Token Calculator

Pick whether you are starting from a word count or a character count, enter the number, and choose a model. The calculator returns an estimated token count plus two prices: what those tokens cost sent to the model as input, and what the same count costs coming back as output. The two lines stay separate because every model priced below bills output at five to six times its input rate — 2,000 tokens costs $0.0060 going into Claude Sonnet 5 and $0.0300 coming back out.

The two rules of thumb

LLM APIs meter tokens, not words. A token is a chunk of text the model's tokenizer has learned to treat as one unit — sometimes a whole common word, sometimes a fragment like "iz" or " ing", sometimes a single punctuation mark. For ordinary English prose, two approximations have held steady across several generations of tokenizers: one token is about four characters, and one token is about three-quarters of a word.

tokens ≈ words × 4 ÷ 3

tokens ≈ characters ÷ 4

The calculator rounds the estimate to the nearest whole token, then prices it against the selected model's published per-million-token rates:

cost = tokens ÷ 1,000,000 × rate per 1M

The defaults sit at the point where the two paths agree. 1,500 words × 4 ÷ 3 = 2,000 tokens, and 8,000 ÷ 4 = 2,000 tokens as well. The two rules only line up when text averages about 5.3 characters per word including spaces; ordinary English prose runs closer to six, so on the same passage the character path usually returns a slightly higher count than the word path.

Where token counting came from

The tokens you are pricing sit at the meeting point of two histories: an old compression trick and a very new billing model.

The algorithm underneath most modern tokenizers is byte pair encoding, described by Philip Gage in the February 1994 issue of C Users Journal purely as a way to compress data. Gage's method was mechanical. Scan a file for the most frequent pair of adjacent bytes, replace every occurrence with a single unused byte, record the substitution, and repeat until no further pair is worth merging. It sat in the compression literature for two decades before anyone pointed it at language. Rico Sennrich, Barry Haddow and Alexandra Birch, working on neural machine translation at the University of Edinburgh, repurposed it in a paper first circulated in August 2015 and published at ACL 2016. Instead of shrinking a file, they ran the same merge-the-frequent-pair loop over a training corpus to build a fixed vocabulary of subword fragments, so a model could spell a rare or never-seen word out of pieces it already knew rather than failing on it entirely.

Related methods grew up alongside it. WordPiece, set out by Mike Schuster and Kaisuke Nakajima in a 2012 Google paper on Japanese and Korean voice search, merges pairs by how much each merge raises the likelihood of the training text rather than by raw frequency; it went on to tokenize Google's BERT in 2018. SentencePiece, released by Taku Kudo and John Richardson that same year, trained subword models straight from raw text without assuming space-separated words, which made it workable across writing systems. OpenAI's GPT-2 in 2019 settled on byte-level BPE, running the merges over raw bytes rather than characters, with a vocabulary of 50,257 entries. That design is the one most current models still echo, only larger: the o200k tokenizer OpenAI shipped with GPT-4o in 2024 carries roughly 200,000 entries, and a bigger vocabulary packs the same prose into fewer tokens.

Per-token pricing is much younger than the algorithm that produces the tokens. OpenAI opened the GPT-3 API on 11 June 2020 and began charging for access later that year, metering what customers consumed in tokens rather than in words, characters or whole requests. Published rates followed per thousand tokens, one line for each of the ada, babbage, curie and davinci engines, all four of which OpenAI later retired in January 2024. The unit itself stuck. Anthropic and Google bill in tokens as well, and as rates fell every provider restated the same figures per million tokens, which is the form the table below uses. That convention is the reason a calculator like this one has to turn your text into tokens before it can name a price at all.

Worked examples at three scales

A blog post. You paste a 1,500-word draft into Claude Sonnet 5 for editing. That is 2,000 tokens of input: 2,000 ÷ 1,000,000 × $3 = $0.0060. If the model rewrites the whole piece, the reply is another 2,000 tokens or so of output: 2,000 ÷ 1,000,000 × $15 = $0.0300. The full round trip is under four cents, which is why nobody optimizes single-document workflows.

A documentation corpus. A startup wants to tag 400 help-center articles averaging 900 words each. That is 360,000 words, or 480,000 tokens of input. Through Gemini 3.6 Flash at $1.50 per million: 480,000 ÷ 1,000,000 × $1.50 = $0.72. The classification labels coming back might be 30 tokens per article — 12,000 tokens × $7.50 per million = $0.09. The entire corpus costs less than a dollar, so the real question is prompt quality, not price.

A catalog rewrite. A retailer generates 50,000 product descriptions at 120 words each. Output is what matters here: 6,000,000 words, or 8,000,000 tokens generated. On Claude Haiku 4.5 at $5 per million output that is $40. On Sonnet 5 at $15 it is $120, and on Opus 4.8 at $25 it is $200. At this scale the model choice moves the bill by 5x while the input prompt is a rounding error.

Why real tokenizers disagree with the estimate

Four things push actual counts away from the rules of thumb.

• Code. Identifiers like getUserById split into several tokens, symbols and operators each cost one, and indentation adds up. Source code commonly runs 20 to 40 percent more tokens than the character rule predicts, though modern tokenizers with dedicated whitespace tokens have narrowed the gap.
• Non-English text. Tokenizer vocabularies are weighted toward English. French or German prose costs perhaps 10 to 30 percent more tokens per word, and non-Latin scripts historically cost two to three times as many, though the newest tokenizer generations have improved substantially for major world languages.
• Whitespace and structure. JSON, YAML, markdown tables and log files carry quotes, brackets and repeated keys that tokenize into many small pieces relative to their information content.
• Tokenizer generation. Vocabulary sizes have grown from roughly 50,000 entries in the GPT-2 era to around 200,000 in current tokenizers. A larger vocabulary compresses the same text into fewer tokens, which is one reason counts differ between models from the same provider.

When the estimate is inside 10 percent

For plain English prose — articles, emails, documentation, chat transcripts — the word rule reliably lands within 5 to 10 percent of the count a real tokenizer reports. Expect it to drift beyond that on source code, minified data, base64 blobs, long URLs, dense numeric tables and text in languages other than English. When the exact count matters, such as checking whether a document fits a context window, use the provider's own counter: OpenAI ships the tiktoken library, Anthropic exposes a count-tokens endpoint, and Gemini has a countTokens method in its SDKs. For budgeting, the estimate here is usually all you need.

Current per-million rates

The model menu prices against the rates below, in USD per million tokens, taken from each provider's published API pricing and verified July 2026.

This page answers the one-off question — what does this document cost. To turn a request volume and token profile into a monthly bill across models, use the LLM API cost calculator.

Prices change without notice and figures here are estimates, not quotes; this site is not affiliated with any provider named above. See the site disclaimer.

Frequently asked questions

How many tokens is 1,000 words?

About 1,333 tokens using the three-quarters rule — 1,000 × 4 ÷ 3. Real tokenizers land close to that on plain English prose: a 1,000-word article typically comes back between 1,250 and 1,400 tokens depending on vocabulary and punctuation.

How many words fit in a 128,000-token context window?

Roughly 96,000 words at 0.75 words per token, which is a full-length novel. In practice you need headroom for the system prompt, conversation history and the model's answer, so 70,000 to 80,000 words of source material is a more realistic ceiling.

Do GPT, Claude and Gemini count tokens the same way?

No. Each provider trains its own tokenizer with its own vocabulary, so the same text produces different counts on each API — usually within 10 to 20 percent of one another on English prose, and much further apart on code or non-Latin scripts. This calculator uses provider-neutral rules of thumb rather than any single tokenizer.

Why does my API bill show far more tokens than this estimate?

The bill meters the whole request, not just your document. The system prompt, tool definitions, prior conversation turns and per-message overhead all bill as input on every call, so a 500-token question inside an agent with a 3,000-token system prompt costs at least 3,500 input tokens per turn.

How many tokens is a 10,000-character JSON file?

The naive estimate is 2,500 tokens, but structured data tokenizes worse than prose — braces, quotes and short keys break into extra pieces — so 3,000 to 3,500 is common. Minifying the JSON and shortening key names can cut the real count by 20 to 30 percent.