Skip to content
    All tools
    Free Tool

    LLM Token Counter & Context Budgeter

    Paste any text to estimate its token count and see how much of each model's context window it uses — from 8K to 1M.

    Tokens (est.)
    0
    Words
    0
    Characters
    0
    Context-window fit
    8K legacy / small—
    32K GPT-4 32k—
    128K GPT-4o / Llama—
    200K Claude—
    1M Gemini 1.5/2—

    Estimate only (~4 chars/token for English prose). Exact counts vary by model and tokenizer — code, non-English text, and rare words tokenize differently. Planning a budget by cost instead? Try the LLM Cost Estimator →

    What this tool does

    This tool estimates how many tokens a piece of text will use and shows how much of five common context-window sizes it would fill. Paste a system prompt, a document or a retrieved chunk and the counts update as you type.

    It is for planning: sizing a prompt, deciding whether a document can be sent whole or needs splitting, or checking a RAG design against a model's limit. It answers "roughly how big is this, and does it fit?", not "what exactly will this cost?".

    The number comes from a fixed rule, not a real tokenizer. For a hard limit or a cost forecast, confirm with the tokenizer or token-counting endpoint of the model you use.

    How it works

    The tool counts characters, words and estimated tokens in the text box, then divides the token estimate by each built-in window size to show a percentage used, or a multiple over the limit. The calculation runs on the text in the page and the tool's code makes no network request for it.

    Characters
    chars = text.length
    Words
    words = count of whitespace-separated runs (0 if empty)
    Estimated tokens
    tokens = round(chars / 4)
    Under a window
    pct = tokens / window x 100, shown as N% used (whole number, or one decimal below 1%)
    Over a window
    tokens / window to one decimal, shown as Nx over

    What it assumes

    • 4 characters per token is a rough average for English prose. Code, non-English text, numbers and rare words usually produce more tokens per character, so the real count can be higher.
    • The built-in windows are 8K (8,192 tokens), 32K (32,768), 128K (128,000), 200K (200,000) and 1M (1,000,000), labelled with example model families. They are approximations that change over time, and the code carries no date or version for them.
    • Only the pasted text is compared to each window. Space for the model's reply, history and any unpasted instructions is not reserved.
    • Characters are JavaScript string length, so an emoji counts as two, and text written without spaces counts as few words. A single character rounds to 0 tokens.

    Worked example

    Illustrative: a long document of 36,000 characters (roughly 6,000 words of English) that you are considering sending in one request.

    Example inputs (illustrative)
    InputValue
    Text length36,000 characters (illustrative)
    Chars per token (built in)4
    1. Estimated tokens = round(36,000 / 4) = 9,000.
    2. 8K (8,192): 9,000 is above it, and 9,000 / 8,192 = 1.0986, shown as 1.1x over.
    3. 32K (32,768): 9,000 / 32,768 x 100 = 27.47%, shown as 27% used.
    4. 128K (128,000): 9,000 / 128,000 x 100 = 7.03%, shown as 7% used.
    5. 200K (200,000): 9,000 / 200,000 x 100 = 4.5%, shown as 5% used.
    6. 1M (1,000,000): 9,000 / 1,000,000 x 100 = 0.9%, shown as 0.9% used.

    About 9,000 tokens (estimated): 1.1x over the 8K window, 27% of 32K, 7% of 128K, 5% of 200K and 0.9% of 1M.

    Frequently asked questions

    How accurate is the token count?
    It is a planning estimate at 4 characters per token, typical for English prose. Real tokenizers vary by model and content, so use the provider's own counter when the exact number matters.
    Why would code or non-English text be undercounted?
    Tokenizers split text into pieces learned from training data. Code, symbols, numbers and many non-English languages tend to break into more pieces per character than the flat 4-character rule assumes.
    If my text fits a window, will the request succeed?
    Not necessarily. The window usually has to hold instructions, retrieved context, conversation history and the model's output together, and this tool measures only what you paste. Leave headroom.
    Is my text sent anywhere?
    The counter's code makes no network request. The text stays in the page's state while you use it.
    What if my text is over a window?
    Shorten or summarise it, or split it into chunks and retrieve only the relevant ones. The guides below cover token budgets, chunking and context engineering. For spend rather than size, the LLM Cost Estimator on this site prices tokens at rates you enter.

    Read the guide

    Building this for real?

    I help teams design and ship AI systems — cost modelling, RAG, agents, and architecture.

    Work with me