Approximate prompt token inspector
AI Token Visualizer
Visualize approximate token-sized text chunks, inspect prompt composition, and estimate context-window usage with reserved output capacity.
Approximate token analysis
Character heuristic and context capacity
Fits the selected context window
The approximate prompt and output reserve remain below the selected limit.
20
12.45%
7,172
After reserving output tokens
80
12
Calculation basis
- Characters per token
- 4
- Lines
- 1
- Reserved output
- 1,000 tokens
- Context window
- 8,192 tokens
Approximate token boundaries
Spaces are shown as ·, line breaks as ↵, and tabs as ⇥.
Letters
68
Digits
0
Whitespace
11
Symbols
1
Formula
How approximate token visualization works
The visualizer groups Unicode characters using a configurable characters-per-token heuristic. It does not reproduce a provider tokenizer.
Estimated input tokens = ceil(Unicode characters ÷ characters per token)
Projected total tokens = estimated input tokens + reserved output tokens
Remaining input capacity = context window − reserved output − estimated input
export function approximateTokens(
text: string,
charactersPerToken = 4,
) {
const characters = Array.from(text);
const chunks: string[] = [];
for (
let index = 0;
index < characters.length;
index += charactersPerToken
) {
chunks.push(
characters.slice(index, index + charactersPerToken).join(""),
);
}
return {
estimatedTokens: chunks.length,
chunks,
};
}Example prompt inspection
A four-characters-per-token heuristic is useful for early English-language planning, but code, structured data, emojis, and non-English text can differ significantly.
Use the context controls to reserve room for the model response. For exact billing or hard context limits, run the provider's tokenizer for the exact model and serialized request.
What this estimate includes
- Unicode character, word, and line counts
- Approximate token-sized text chunks
- Letter, digit, whitespace, and symbol composition
- Projected context usage and remaining input capacity
Frequently asked questions
Are the displayed chunks real model tokens?
No. They are transparent character groups used for planning. Actual token boundaries depend on the model vocabulary, tokenizer version, language, whitespace, and request formatting.
Why use four characters per token?
It is a common rough estimate for English prose. Adjust the input when you have observed tokenizer ratios for your content.
Does the context estimate include the response?
Yes. Reserved output tokens are added to the estimated input tokens so the projected total can be compared with the selected context window.
What else consumes context?
System instructions, tool definitions, message wrappers, retrieved documents, images, hidden provider formatting, and prior conversation turns may consume additional context.
Related calculators
Text-to-Token & Cost Estimator
Estimate input tokens and project OpenAI, Gemini, or Claude API spend.
OpenEmbedding Cost Calculator
Estimate embedding costs from text volume, chunks, and refresh rate.
OpenLLM Latency Estimator
Model time to first token, full response latency, and concurrent capacity.
OpenRelated glossary terms
Input tokens
Input tokens are the tokenized units sent to a model, including instructions, user content, conversation history, retrieved context, and tool definitions.
OpenRequests per day
Requests per day is the number of billable API calls made during a day. TokenMath commonly derives it from requests per active user multiplied by active users.
OpenCost per request
Cost per request is the sum of all billable usage generated by one API call, commonly input token cost plus output token cost for a text model.
Open