Token Counter & Context-Window Fit (with boundary view)

Methodology & privacy

Token counting here uses real byte-pair-encoding (BPE) tokenizers, not a word or character estimate, for two of the five models shown. The exact counts come from js-tiktoken, a JavaScript port of OpenAI's own tiktoken library, running two of its published encodings entirely in your browser: o200k_base, the encoding behind GPT-4o, GPT-4.1, and OpenAI's o-series models, and cl100k_base, the encoding behind GPT-4, GPT-3.5, and OpenAI's embedding models. BPE splits text into subword units built by repeatedly merging the most frequent adjacent byte pairs seen in a large training corpus, so common words are usually a single token, longer or rarer words split into a few, and whitespace and punctuation get their own tokens. That is also why a token count differs from a word or character count, and why the exact same text can tokenize to a different length under a different encoding: the same 61-character Chinese sentence comes out to 36 tokens under o200k_base but 58 under cl100k_base, a 61% difference for identical content, because the two encodings were trained with different vocabularies. The boundary visualization is built by decoding each token id back to text on its own, so the highlighted spans, concatenated in order, reconstruct the exact original text; rendering stops after 2,000 tokens purely to keep the page responsive, and the count itself stays exact and unaffected by that cap. Claude, Llama 3, and Gemma do not ship a tokenizer that is practical to lazy-load in a browser tab: Claude's tokenizer isn't published at all, and Llama 3 and Gemma's real vocabularies are large binary files not worth the download for a rough number. Those three rows use a characters-per-token ratio instead, 3.5 characters per token for Claude, 3.8 for Llama 3, and 4.0 for Gemma, rough averages for general English prose. Every row using this shortcut is flagged as an estimate and rendered separately from the exact rows, never blended in as if it were a real count, and it can be off by a meaningful margin on code, non-English text, or unusual formatting, exactly where a character ratio and a real tokenizer diverge most. The context-window fit bars divide your token count by five common context sizes, 8,000, 32,000, 128,000, 200,000, and 1,000,000 tokens, and multiply by 100, capping the displayed percentage at 999% so an extreme count never breaks the layout. These five sizes are round figures representative of widely used tiers rather than one exact model each: 128K matches GPT-4o and GPT-4.1's published context window, and 200K and 1M match Claude's smaller and its current largest-context models; 8K and 32K stand in for smaller legacy and local-model tiers. Providers change context windows over time, so treat the fit bars as a check against common size tiers, not a live lookup of any single model's current limit.

• Source: Quora: How long of a prompt can I give ChatGPT?
• Source: Quora: How does ChatGPT remember the beginning of the conversation if it does not have a state and input size is limited?
• Source: Reddit r/LocalLLaMA: context parsing utility (counts tokens with tiktoken)
• Source: js-tiktoken (JavaScript port of OpenAI's tiktoken, used for the exact counts)
• Source: openai/tiktoken: model-to-encoding mapping (o200k_base / cl100k_base)
• Source: OpenAI API docs: GPT-4o model page (128,000 token context window)
• Source: Anthropic docs: Claude models overview (context window by model)

Every keystroke stays on your device. The tokenizer files load once from your browser's own network request after your first keystroke, but the text you type, the resulting counts, and the boundary view are all computed in local JavaScript and never sent to a server, logged, or stored anywhere.