How Many Tokens Are in 1,000 Words? A Practical Guide for AI Writers

Short answer: 1,000 English words are often about 1,300 to 1,400 tokens. A commonly cited OpenAI rule of thumb—one token is roughly 0.75 English words—puts 1,000 words at about 1,333 tokens.
That is an estimate, not a universal conversion. The exact result changes with the model and tokenizer, language, punctuation, formatting, URLs, numbers, and code. If you are planning an article workflow, use 1,333 tokens as an early estimate, allow extra room for structured or technical content, and test the final request against the endpoint you will actually use.
This guide explains how many tokens are in 1,000 words, what makes the number move, and how AI writers can turn a rough word count into a safer request budget.
1,000 words to tokens: the practical estimate
For ordinary English prose, this is a useful planning table:
| Content | Rough token estimate | How to use it |
|---|---|---|
| 1,000 words of clean English prose | 1,300–1,400 | Good first-pass editorial estimate |
| 1,000 words with many headings, links, numbers, or unusual names | 1,400–1,600+ | Add room for punctuation and less common text patterns |
| 1,000 words containing code, JSON, tables, or dense technical strings | Test directly | Word count becomes a weak predictor |
| A complete AI request built around a 1,000-word draft | More than the draft alone | Add system instructions, history, examples, tools, and output reserve |
The range above is intentionally practical rather than absolute. OpenAI explains that, in English, one token is roughly four characters or 0.75 words. Dividing 1,000 by 0.75 gives approximately 1,333 tokens.
Google’s Gemini token documentation offers another useful English rule of thumb: 100 tokens are about 60 to 80 English words. Reversing that range places 1,000 English words at roughly 1,250 to 1,667 tokens. The wider range is a reminder that “1,000 words to tokens” is an estimate until the target model counts the actual text.
Why 1,000 words do not always equal the same number of tokens
Words are editorial units. Tokens are model-processing units. A token can represent a short word, part of a long word, punctuation, a number fragment, a whitespace pattern, or part of a character sequence.
That means two documents with exactly 1,000 words can produce different token totals.
1. The tokenizer and model matter
Different model families can use different tokenizers or vocabulary versions. A sequence represented efficiently by one tokenizer may be split into more pieces by another. Even when two models accept the same visible text, you should not assume they will report identical usage.
Use an official provider counting method when one is available. Anthropic, for example, provides a token-counting endpoint for estimating message input before sending it, while noting that the estimate may differ slightly from actual usage. The operational source of truth is still the usage returned by the completed API request and, ultimately, the provider’s billing records.
2. Language changes the ratio
The 0.75-words-per-token heuristic is specifically useful for English. It should not be applied blindly to Chinese, Japanese, mixed-language copy, or translated content.
Chinese does not place spaces between every word, so “word count” itself is not directly comparable with English word count. Multilingual tokenizers also segment scripts differently. If you are producing an English article and a Chinese localization, count and budget each version separately rather than applying one conversion ratio to both.
For more detail, read why Chinese prompts can use different token budgets than English prompts and the guide to token counting for English–Chinese translation workflows.
3. Punctuation, URLs, and numbers can increase the count
An article full of ordinary sentences usually behaves more predictably than a page containing:
- long tracking URLs;
- prices, dates, SKUs, and percentages;
- hyphenated product names;
- uncommon proper nouns;
- emoji and symbols;
- citation markup;
- repeated punctuation.
These elements may split into several tokens even when a writer sees them as one “word” or one compact string. This is why a 1,000-word glossary page, product comparison, or technical tutorial may need more tokens than a 1,000-word narrative article.
4. Markdown, HTML, JSON, and code add structure
AI writing workflows often send more than visible prose. Your request may include Markdown headings, link destinations, HTML tags, a JSON output schema, or a content brief with labeled fields.
Compare these two instructions:
Write a concise summary of the article.
{
"task": "summarize",
"format": "json",
"required_fields": ["title", "summary", "keywords", "cta"]
}
The second version carries useful structure, but that structure also consumes input tokens. If the 1,000 words sit inside a larger template, count the template too.
5. The complete request is larger than the article
The most common budgeting mistake is counting only the visible draft. A real request may contain:
- a system prompt;
- the 1,000-word source article;
- brand voice rules;
- a keyword brief;
- examples or reference passages;
- previous conversation turns;
- tool definitions or an output schema;
- the model’s generated response.
If a 1,000-word draft is approximately 1,333 input tokens, a full editing request might still be much larger. You also need to reserve output tokens for the rewrite, recommendations, metadata, or structured response.
To understand the distinction, see token count vs character count.
A simple calculator for 1,000 words
For a first-pass English estimate, use:
estimated tokens = word count ÷ 0.75
Examples:
| Word count | Estimate using 0.75 words per token |
|---|---|
| 250 words | 333 tokens |
| 500 words | 667 tokens |
| 1,000 words | 1,333 tokens |
| 1,500 words | 2,000 tokens |
| 2,000 words | 2,667 tokens |
This formula is useful for planning. It is not a substitute for model-specific counting.
Add a working buffer
If you only know the word count, a practical workflow is:
- Estimate 1,000 clean English words at about 1,333 tokens.
- Raise the input allowance to around 1,500 tokens when the draft contains links, numbers, Markdown, or technical terminology.
- Add every instruction, example, reference, and prior message.
- Reserve output tokens separately.
- Run the exact request against the target endpoint before scaling.
The buffer is not a tokenizer fact. It is an operational safety allowance for content you have not counted yet.
Input tokens, output tokens, and cost planning
When AI writers ask how many tokens are in 1,000 words, they are often trying to estimate cost. That requires at least two numbers:
total request usage = input tokens + output tokens
For example, imagine an editing workflow with:
- 1,333 estimated tokens for the 1,000-word article;
- 300 tokens of instructions, keywords, and brand rules;
- up to 700 output tokens for the edited copy and notes.
The working budget is now about 2,333 tokens, not 1,333. If the workflow runs a second fact-check or localization call, budget that request separately.
Do not multiply a token estimate by a price remembered from another model. Input and output rates can differ, cached input may be treated separately, and current pricing is model-specific. Use the provider’s current pricing page and the exact usage categories returned by your endpoint.
Three tests to run in TokenTest
TokenTest is useful here as a live endpoint evaluation layer. Use an official tokenizer or counting endpoint for preflight estimates, then run the actual request and inspect whether the endpoint returns plausible token usage alongside the response.
Test 1: Plain prose versus formatted prose
- Send a 1,000-word plain-text article to the target endpoint.
- Send the same article with Markdown headings, links, a table, and metadata fields.
- Compare reported input and total token usage.
The visible word count may remain close to 1,000 while the request structure changes.
Test 2: Draft alone versus complete editorial brief
Run the draft first. Then repeat with a system prompt, search intent, audience description, required headings, internal-link targets, and output schema.
This demonstrates why counting only the article understates the real input budget.
Test 3: English versus Chinese localization
Test the English article and a reviewed Chinese localization as separate requests. Do not expect equal word, character, or token ratios. Compare the actual usage returned by the same endpoint and record the result for future bilingual planning.
If you already have a raw OpenAI-compatible response, TokenTest’s offline JSON analysis can also help you inspect the response and usage fields without making another live request.
Common mistakes when converting words to tokens
Treating 1,333 as an exact count
It is a rule-of-thumb result based on English averages. It is not a guaranteed count for every 1,000-word file.
Counting only the user-visible article
System messages, chat history, schemas, tools, and reference context can materially increase input usage.
Reusing the English ratio for Chinese
English word-based heuristics are not reliable for Chinese localization. Count each language with the target model.
Ignoring output tokens
A rewrite, outline, metadata package, or translation consumes output tokens. Cost and context planning must reserve room for that response.
Trusting a generic calculator as final billing truth
Generic calculators are useful estimates. The target model’s official counter, endpoint-reported usage, and billing records are the stronger evidence chain.
A practical token-budget checklist for AI writers
Before submitting or scaling a 1,000-word workflow, confirm that you have:
- estimated the source draft at roughly 1,300 to 1,400 tokens for clean English prose;
- counted or allowed for instructions, briefs, examples, links, and formatting;
- treated code, JSON, tables, URLs, and multilingual text as separate test cases;
- reserved output tokens for the requested deliverable;
- used the target provider’s official counting method where available;
- verified the complete request against the live endpoint;
- recorded actual input, output, total, and cached usage when returned;
- rerun the baseline after changing the model, prompt template, or content type.
Frequently asked questions
How many tokens are in 1,000 English words?
About 1,333 tokens is a useful rule-of-thumb estimate. In practice, 1,300 to 1,400 tokens is a sensible starting range for clean English prose, but the exact total depends on the tokenizer and text.
Is 1,000 tokens the same as 1,000 words?
No. Using the 0.75-words-per-token English heuristic, 1,000 tokens correspond to roughly 750 words. That relationship varies by content and model.
How many tokens are in a 1,000-word blog post with links?
Usually more than the same post without links, especially when URLs are long or the article includes metadata, Markdown, tables, and unusual names. Use 1,500 tokens as a cautious planning allowance, then count the exact request.
Does punctuation affect token count?
Yes. Punctuation and adjacent whitespace are part of the text patterns a tokenizer segments. Heavy punctuation, symbols, and structured syntax can change the result.
Should I estimate tokens from words or characters?
Words are convenient for English editorial planning, while characters can support another rough estimate. Neither replaces model-specific token counting. For production work, count the complete request with the target provider’s official method where available.
Can TokenTest tell me the final bill?
TokenTest can help evaluate endpoint behavior and inspect returned usage, but the provider’s billing records remain the final billing source. Treat endpoint-reported usage as operational evidence and reconcile it with invoices or billing exports.
The bottom line
If you need a quick answer to “how many tokens are in 1,000 words?”, start with about 1,333 tokens for English. For everyday planning, think 1,300 to 1,400 tokens for clean prose and allow more for links, formatting, code, or technical text.
Then stop estimating. Count the complete request with the target model, reserve the output separately, and test the live endpoint in TokenTest before turning one article into a high-volume workflow.