Token Counter
Paste any text. See live character, word, and token counts — plus dollar cost and context-window usage — for 7 frontier models. Switch models with a click. Everything happens in your browser; nothing is sent anywhere.
🔢 Live Token Counter
Characters → tokens → dollars. Everything updates as you type.
Your text
Stats — GPT-4 Turbo
Same text, different models
How the same characters map to tokens and dollars across all 7 models. The cheapest and priciest are highlighted.
Why a character ratio is a fast approximation
Real tokenizers don't see characters — they see BPE merges (byte-pair encoding). OpenAI's cl100k_base tokenizer, used by GPT-4, was built by iteratively merging the most frequent byte pairs in a huge training corpus. The result: a "token" can be a single character (like a), a short word (cat), or a chunk of a long word. There's no clean char-to-token map.
But here's the cheat: across English text, the average character-to-token ratio is remarkably stable. One GPT token represents roughly 4 characters of English. Claude's tokenizer runs closer to 3.5. DeepSeek around 3.8. Llama 4 around 3.4. The numbers wobble for code, numbers, and non-English text, but for budgeting purposes they hold within ±15%.
This counter uses the ratio method. It runs in microseconds with no dependencies and works in any browser. A real tokenizer would need a 2MB BPE table fetched over the network, add 50ms of latency, and fail on the very first unicode cluster. The ratio is "good enough" for cost planning, context budgeting, and quick estimates.
Why each model has a different ratio
Tokenizers are tuned to the training data they were built on. GPT-4's tokenizer was trained on a multilingual web crawl with heavy English bias. Claude's tokenizer was trained on a curated mix favoring longer, well-formed prose. DeepSeek's leans toward code. Llama 4's compresses common English words into single tokens.
The practical consequence: the same paragraph costs you different numbers of tokens on each model. Below is the live ratio for each model in this counter:
A sentence like "The quick brown fox jumps over the lazy dog" (43 chars) lands at 11 tokens on GPT-4 (~3.9 chars/tok), 12 on Claude (~3.6), 9 on Llama 4 (~4.8). Code inverts the order: a Python dictionary literal can be 30% cheaper on DeepSeek than on GPT-4 because DeepSeek's merges favor punctuation patterns.
This is why model-specific counters matter. Estimating with a generic 4.0 ratio and then submitting to a different provider can surprise you when the bill arrives.
The cost formula, end to end
Every frontier model charges per million tokens. Input (your prompt) and output (the model's reply) are usually priced separately, with output often 3–5× more expensive. The math is straightforward:
The output cost heuristic in this counter uses input tokens × 0.5 as a placeholder. That's a rough average: a Q&A prompt typically produces a shorter answer (~0.3× input), while a "explain in detail" prompt can produce 2–4× more output than input. The 50% midpoint keeps the number reasonable until you supply real output counts. For serious budgeting, run a sample through and replace the heuristic with your observed ratio.
Reading the context window gauge
Every model has a hard ceiling on how much text it can read in one call — the context window. Claude 3.5 Sonnet gives you 200K tokens. GPT-4 Turbo gives 128K. Llama 4 stretches further on some endpoints. The gauge shows where your text sits relative to that ceiling, in three bands:
The bands aren't arbitrary. Research on long-context benchmarks (Lost in the Middle, Liu et al. 2023) shows performance degrades gradually above 50% of training context, and cliff-drops past 80% as out-of-distribution positions squeeze the model's attention. The 50/80 split is a working heuristic, not a guarantee from any vendor.
Design decisions, tradeoffs, what I'd improve
This is the part of the build docs usually left out: the choices that didn't make the README. If you fork this counter, here's what to watch for.
A real BPE tokenizer adds 1–3 MB of bundle weight and a WASM/Web Worker layer. The ratio heuristic loads in 0 KB and runs in <1 ms per recalculation. For a "budget before you submit" tool, the bundle savings dominate. If you want to bill accurately, swap in tiktoken via WASM or hit the provider's tiktoken endpoint.
Most token counters wait for a "Calculate" button. This one updates on every keystroke, paste, and cut. The cost is <0.3 ms per event for a 10K-character textarea, which is imperceptible. The win is the live feedback loop — you watch the bars move as you delete a paragraph, which is genuinely useful when you're trimming context.
Honest disclosure: the output cost is a placeholder. I picked 50% as the median of "Q&A" and "long-form" use cases. A real estimate would let you set the expected output ratio per model and per task type. Adding that as a slider would be the single highest-value improvement, and I should do it next.
Some vendors (Anthropic with prompt caching, OpenAI with cached input) charge less for repeated context. The gauge shows raw token usage, not cached usage. A cache-aware counter would mark "this segment is <cache hit>" and the cost would drop accordingly. Skipped for v1; documentation earns its place.
A diff mode: paste two versions of the same prompt and see the token-count delta side-by-side. A "save to library" feature so you can compare draft prompts over time. A bulk mode where you paste a CSV of prompts and get a token-cost spreadsheet. All tractable; all skipped for the v1 scope.