Tokens per Word: GPT-5 vs Claude vs GPT-4, Measured Across 7 Languages

SAVI — Wed, 10 Jun 2026 20:32:58 +0000

Most token-cost guides repeat the same rule of thumb: one token is about three quarters of an English word. That figure is roughly right for English on a modern tokenizer, and increasingly wrong for everything else. Published numbers are surprisingly thin, so we measured it.

Method

We built a 13-sample corpus: the same 94-word passage human-translated into English, Spanish, Portuguese, French, German, Chinese, and Japanese (so the comparison holds meaning constant, not length), plus Python, JavaScript, JSON, Markdown, emoji-heavy social text, and CSV data.

GPT counts come from tiktoken (o200k_base for GPT-5/4o, cl100k_base for GPT-4, p50k for the GPT-3 era), so they are exact. Claude counts come from Anthropic's official count-tokens endpoint, envelope-calibrated (we measured the fixed message wrapper of 6 to 7 tokens and subtracted it; a doubling check came back with zero drift).

Tokens per word, same passage

Language	Words	GPT-5 (o200k)	Tokens/word	GPT-4 (cl100k)	Claude Sonnet 4.6	Claude Opus 4.8
English	94	110	1.17	110	116	177
Spanish	107	143	1.34	172	184	256
Portuguese	102	137	1.34	176	188	241
French	109	153	1.40	194	207	275
German	93	159	1.71	203	245	324
Chinese	n/a	159	n/a	223	217	216
Japanese	n/a	205	n/a	268	241	240

The four findings that surprised us

Spanish costs +30% vs English on GPT-5, but it used to be much worse. The same passage was +56% on GPT-4's cl100k and more than double on the GPT-3 era p50k. o200k roughly doubled the vocabulary and spent it on human languages.
Claude has two counting regimes. Anthropic's count-tokens endpoint reports identical numbers for Sonnet 4.6 and Haiku 4.5, but roughly 1.5x higher for Opus 4.8 on Latin-script text (Chinese and Japanese barely change). Since billing follows each model's own count, Opus costs about 2.5x Sonnet per English word despite a 1.67x sticker ratio.
CSV is the most expensive thing you can send. 57 tokens per 100 characters vs 19 for English prose. Digits, dates, and separators fragment into many small tokens.
o200k did not help code. Our JavaScript sample actually costs slightly more on o200k than cl100k. The multilingual gains came at no benefit to source code.

What a million words costs (input, measured)

Language	GPT-5	Claude Haiku 4.5	Claude Sonnet 4.6	Claude Opus 4.8
English	$1.46	$1.23	$3.70	$9.41
Spanish	$1.67	$1.72	$5.16	$11.96
German	$2.14	$2.63	$7.90	$17.42

Reproduce it

The full dataset, corpus, and methodology are free under CC BY 4.0:

Full article with all tables
tokenizer-comparison-2026.csv and JSON
The 13-sample corpus, so you can verify every count

To sanity-check the GPT numbers interactively, our browser-local token counter runs the real o200k encoding client-side, so counts match this dataset exactly and your text never leaves the page.

Validating JSON in 2026: Browser vs VS Code vs jq

SAVI — Thu, 07 May 2026 17:33:03 +0000

Last week I watched a senior engineer paste a 4MB JSON payload into VS Code and wait 12 seconds for the linter to finish. Then they Cmd+F'd for the missing bracket. Then they gave up, re-ran the API call, and tried again.

That whole detour was unnecessary. There are three places JSON validation lives in 2026 — the browser, the editor, and the shell — and each one wins in a different scenario. Mixing them up costs a few minutes a day. Once you stop mixing them up, you stop noticing the friction at all.

This is a field guide to which tool actually wins for which task.

Why "just use VS Code" is wrong

VS Code's built-in JSON validator is excellent. It is also the worst answer to several common questions, because:

It loads the whole file into memory. A 50MB log dump from CloudWatch hangs the renderer for seconds before you can scroll.
It validates syntax, not shape. Without a $schema reference, you get a green checkmark for any structurally valid blob — no help with "is this the response my API returned yesterday?"
It is coupled to a workspace. Pasting an ad-hoc payload into a scratch buffer means picking a filename, picking a folder, and ignoring unsaved-buffer warnings on quit.
It is not on the production server. When you SSH into a box at 2am to inspect what an API returned, the editor is irrelevant.

VS Code is right when JSON is part of a project — config files, fixtures, schema-validated payloads. It is wrong for almost everything else.

When the browser wins

Most JSON validation in practice is one-shot: "is this blob I just pasted valid?" or "what does this nested structure actually look like?"

For that, a browser-based formatter is the fastest answer. No file to save, no buffer to close, no schema to wire up. You paste, you see green or red, you keep moving.

I use TextKit's JSON formatter for this. The reason is boring and important: it pretty-prints, minifies, and validates without sending the payload anywhere. Everything happens client-side. That matters when the JSON contains a customer email or an internal token — and it almost always does, because if it did not, you would not be poking at it.

The browser wins specifically when:

The payload is between 1KB and 5MB (above that, browsers struggle too).
You do not need to query the data, just look at it.
You want to compare two payloads side by side. Format both, then drop them into TextKit's text diff tool — it respects whitespace and shows the structural drift line by line. This is the single fastest way to answer "what changed between yesterday's API response and today's?"
You are on someone else's machine and you do not trust their Node version.

A note on copy-paste hygiene. JSON pulled from server logs usually comes with line numbers, timestamps, or wrapper text glued to it. Cleaning that up by hand is irritating. A regex-capable find and replace can strip the prefix in one pass — the pattern ^\d{4}-\d{2}-\d{2}T[^\s]+\s+ covers the ISO-timestamp prefix that breaks most parsers.

When VS Code wins

VS Code is the right tool when JSON is part of the project, not a one-off blob.

The clearest signal: the file lives in your repo and someone else will edit it next week. That includes:

tsconfig.json, package.json, .eslintrc.json, and the rest of the config family.
API request and response fixtures in a test directory.
OpenAPI specs and JSON Schema definitions where IntelliSense matters.
Any file where Git history needs to track changes

In these cases the editor's schema validation is the entire point. Reach for the browser and you lose Cmd-click navigation, autocomplete, type errors against the schema, and the "Format Document" keybind your hands already know.

A useful trick: if you are handed a JSON payload and you know it is about to become a fixture, paste it into a scratch buffer first, save it as *.fixture.json, and let VS Code start nagging immediately. The friction is the value.

When jq wins

jq is the only correct answer for three things:

JSON over 10MB. No browser, no editor, just stream it.
JSON you need to query, not just read. "Give me the email of every user where subscription.status == 'cancelled'" is a one-liner in jq and a ten-minute exercise in any UI.
JSON inside a pipeline. When the input is curl ... | jq and the output feeds another command, no GUI tool fits.

The jq syntax curve is real, but the floor is low. Three commands cover 80% of practical usage:

bash# Pretty-print and validate (exits non-zero on bad JSON)
cat response.json | jq .

# Pull a nested field out
cat response.json | jq '.data.users[0].email'

# Filter an array by predicate
cat response.json | jq '.data.users[] | select(.status == "cancelled") | .email'

If you are new to jq, the first command alone — jq . — replaces 90% of "is this valid?" workflows once you internalize it. The second and third are what make it irreplaceable.

The cost of jq: it is installed-on-this-machine-or-not, and on Windows the experience is rough enough that most engineers do not bother. That is why the browser tool stays in the rotation even on jq-friendly setups.

A decision tree that fits on an index card

Use this and you will be right 95% of the time:

File is in the repo? → VS Code.
Payload over 10MB, or you need to query inside it? → jq.
One-shot blob, you just want to look at it or share a clean version? → browser-based formatter.
Comparing two payloads? → format both in the browser, diff them, then reach for jq if you need to drill in.

The trap is reaching for VS Code by default because it is already open. It is the most powerful of the three for project work and the slowest for ad-hoc inspection. The browser tool exists for the second category, and the few seconds it saves per inspection compound into real time across a week.

A note on "online JSON validators"

A surprising number of online JSON tools POST your payload to a server. For small public data this is fine. For anything containing PII, internal IDs, API keys, customer records, or anything that ends up in a SOC 2 audit trail — it is not. The fix is to use a tool that runs entirely in the browser and to verify it by opening the network tab and watching for outbound requests during a paste-and-format cycle. If you see none, you are safe.

This is also why "JSON beautifier" search results from 2018 are not a great answer in 2026. Most of those domains were sold, the privacy posture changed, and there is no easy way to audit what they do with what you paste. Pick a tool whose source-of-truth you can verify, then stop thinking about it.

Try it

Next time you are about to paste 200 lines of JSON into your editor's scratch buffer, try TextKit's JSON formatter instead. If it is a structural diff problem, TextKit's text diff takes the formatted output and shows exactly which keys moved.
Save VS Code for the files that actually live in the repo.

DEV Community: SAVI