AI providers bill by tokens, not by words or characters. That makes a long prompt feel cheaper than it is: a 10,000-word document can be tens of thousands of tokens before the model writes a single sentence. The AI token counter estimates input tokens from the pasted text, compares a few default model prices and shows an editable cost table. It is a planning aid, not a billing statement.
Part of the JSON formatter guide. The connection is practical: prompts often carry JSON, code and structured examples, and those characters do not tokenize like ordinary English. The tool is input-only. It does not estimate the model's reply, reserve space for a system prompt or enforce a context window.
How the estimate is produced
The page normalizes the text to Unicode NFC, counts Unicode code points as characters, counts runs of non-whitespace as words, and applies a simple ratio:
- Base estimate = characters / 4
- Code estimate = base x 1.15 when the text looks code-like
- Displayed tokens = rounded up to the next whole token
The code boost triggers on three or more characters from a punctuation set, in a row, that includes braces, brackets, parentheses, semicolons, equals signs, angle brackets, colons, slashes and backslashes, or on keywords such as function, const, import, def and class. It is a single multiplier, not a syntax-aware parser. A string of nested braces or array brackets can trigger the boost, while a plain English paragraph with one colon usually does not. Many ordinary JSON payloads will not trigger it, so the estimate can land low for structured data.
For 4,000 characters of prose, the base estimate is 1,000 tokens. If the same length looks code-like, the estimate becomes 1,150. A 2,000-word article is often around 10,000 to 13,000 characters, which puts the rough range near 2,500 to 3,250 tokens. That is close enough for a budget estimate and far enough from exact to matter when you are near a hard limit.
Characters are counted as Unicode code points, so a simple emoji is one character. A multi-person emoji built from several code points can count as more than one. This is one reason the estimate should be treated as a range rather than a precise count.
Turning tokens into a cost
The cost formula is straightforward:
Input cost = estimated tokens / 1,000,000 x price per million input tokens
The default table uses GPT-4o at 2.50 dollars per million input tokens, Claude Sonnet at 3.00 and Gemini Flash at 0.35. Those are editable starting values, not a live price list. Provider pricing changes, and the same family can have different prices for input, cached input, output, batch processing and long-context tiers.
| Input tokens | GPT-4o at $2.50 | Claude Sonnet at $3.00 | Gemini Flash at $0.35 |
|---|---|---|---|
| 1,000 | $0.002500 | $0.003000 | $0.000350 |
| 10,000 | $0.025000 | $0.030000 | $0.003500 |
| 50,000 | $0.125000 | $0.150000 | $0.017500 |
| 100,000 | $0.250000 | $0.300000 | $0.035000 |
| 1,000,000 | $2.500000 | $3.000000 | $0.350000 |
At 100,000 input tokens, GPT-4o is 0.25 dollars, Claude Sonnet is 0.30 and Gemini Flash is 0.035 on these assumptions. The cheapest model is roughly seven times cheaper for the input portion. That does not automatically make it the best choice: output quality, latency, context limits and output prices can reverse the decision.
The table displays six decimal places. Very small jobs can round to 0.000000 even when the real cost is a tiny fraction of a cent. For a one-off prompt that is harmless; for a high-volume workload, export the token count and calculate against current prices in a spreadsheet instead of reading a rounded display.
What the estimate leaves out
The biggest omission is output. Many providers charge a different, often higher, rate for generated tokens. A prompt with 2,000 input tokens and a 1,000-token response has two billable components, and this page estimates only the first. Add the expected output separately using the provider's output price.
A real request also includes more than the text you paste. System instructions, conversation history, retrieved documents, tool definitions, images and formatting can all consume input tokens. Conversation history grows with every turn, so the tenth message can be far more expensive than the first even when the new question is short. The tool has one text area and no notion of turns.
Context limits are separate from cost. A model may accept a large context but charge more above a threshold, or reject the request when input and reserved output together exceed the window. The counter does not know the selected model's actual context size, does not count the system prompt and does not reserve room for a reply. Check the provider's limit before sending a long document.
Caching, batch discounts, free tiers and reasoning-token billing are not modeled. Those can change the real bill by a large factor. The estimate is most useful for comparing prompt drafts and spotting runaway length before you call an API.
Why a tokenizer still matters
Production tokenizers use byte-pair encoding or a similar scheme. They split common words into single tokens, rare words into pieces, punctuation into separate tokens and code according to learned patterns. Four characters per token is an average for English prose, not a rule. The same 1,000 characters can produce very different counts in English, Chinese, Python, minified JSON or a block of emoji.
Use the page to choose a model and budget a draft. Use the provider's tokenizer or the usage field in an API response when the number affects billing, truncation or a hard limit. If the two disagree by more than a few percent, trust the provider's count for the request you actually send.
Normalization also creates small differences. NFC combines some accented characters, which can change the character count before the ratio is applied. That is reasonable for text comparison, but a provider may tokenize the original byte sequence differently. Keep a margin near limits rather than tuning a prompt to the last estimated token.
A practical prompt-budget workflow
- Paste the exact prompt or document, not a summary of it.
- Read the character, word and estimated-token figures together. A high word count with a low token estimate is a signal to check the text, not a guarantee.
- Replace the default prices with the current input price for the models you are considering.
- Compare the input cost first, then add the expected output cost from the provider's separate output rate.
- Add room for system instructions, history and retrieved context, and confirm the total fits the context window.
- Copy the summary for your notes, then verify the first real request against the provider's usage report.
When a prompt is too expensive, shorten it before changing models. Remove duplicated instructions, replace pasted reference material with a short excerpt, summarize earlier turns, and send structured data in a compact format. The JSON formatter can help you inspect a payload, and the word counter gives a second view of length. Neither replaces a tokenizer, but both make waste easier to see.
The text stays in the page. There is no account, upload or saved history, and the input is capped at 500,000 characters for performance. That cap is a guardrail, not a context-window recommendation; many models accept far less, and some accept more.