The Grain of Language: How a Machine Reads the Internet

Type a sentence into ChatGPT and press enter. In the fraction of a second before any answer begins to form, something happens that feels too mundane to matter and turns out to explain a startling amount about what these systems can and cannot do.

Your sentence is taken apart.

Not into words, exactly, and not into letters. Into pieces of a kind you have almost certainly never thought about — pieces the machine invented for itself before it ever met your sentence. Everything the model does afterward — every association it draws, every fact it recalls, every mistake it makes — happens downstream of this quiet act of disassembly. If you want to understand large language models from the ground up, and I mean genuinely from the ground, this is the ground. So this is where we start.

I have spent a long time teaching difficult technical material to people who are clever but not specialists — clinicians, mostly, and researchers from fields far from computer science. The lesson that experience has burned into me is that understanding almost always fails at the foundation, not the summit. People nod along at "it predicts the next word" and "it's a neural network," and then a hundred pages later nothing quite adds up, because the foundation was skipped. Tokenization is the most-skipped foundation of them all. Books gesture at it in a paragraph and move on. We are not going to move on. By the end of this chapter you will understand it better than most people who use these tools professionally, and you will never look at a chatbot's odd little failures the same way again.

Part I — Where the words come from

Before we can talk about how a model reads, we have to talk about what it reads. And the honest answer, stripped of mystique, is: a very large pile of text, most of it scraped from the open internet.

This sounds almost disappointingly ordinary, and it is worth sitting with the strangeness underneath the ordinariness. A modern language model's entire sense of the world — its grasp of grammar, its store of facts, its imitation of reasoning, its uncanny fluency in dozens of languages — is a statistical residue left behind by an enormous quantity of human writing. There is no encyclopaedia inside it, no database, no rules typed in by hand. There is only text, and what the model managed to internalise by trying, billions of times, to predict what came next in that text. Get the text wrong and everything downstream is wrong. The corpus is not a detail of the build; it is the build.

So where does the pile come from? The starting point, for most of the field, is a remarkable public resource: Common Crawl, a non-profit that has been quietly sending automated crawlers across the web since 2007 and archiving what they find. The scale is difficult to hold in the mind — over 300 billion pages accumulated across fifteen years, with three to five billion fresh pages added every month. It is, in a real sense, a photograph of the readable internet, taken over and over.

But here is the thing nobody tells you: that raw photograph is almost unusable. The open web is, to put it kindly, mostly junk. Spam, boilerplate navigation menus, cookie banners, auto-generated filler, adult content, malware pages, duplicated text copied across ten thousand sites, and markup — endless HTML tags wrapped around the actual prose like packaging around a small gift. Feed that directly to a model and you get a model that has learned the internet's worst habits. The single least glamorous and most decisive part of building a language model is cleaning.

The cleaning is a pipeline — a sequence of filters, each throwing away more of the raw crawl until what remains is something you would actually want a model to learn from.

If you would like to see how meticulous this cleaning actually is, the team at Hugging Face documented one such pipeline in unusual and generous detail for a dataset they call FineWeb — around fifteen trillion words of filtered English text, occupying roughly forty-four terabytes on disk. Read their write-up and one point becomes inescapable: an enormous fraction of the effort in building a frontier model goes not into the clever mathematics you will meet in later chapters, but into deciding, page by page and filter by filter, what counts as text worth learning from. It is the most consequential editorial decision in the field, and it is made almost entirely by engineering.

So: we now have our pile. Tens of terabytes of clean, deduplicated, mostly-English human writing. A model cannot read a terabyte of text any more than it can read your sentence. It reads numbers. Which brings us to the real subject of this chapter — the bridge between text and number, and the surprising cleverness required to build it well.

Part II — Why a machine cannot simply read

Here is a fact that is easy to state and easy to underestimate: a neural network does not process text. It processes sequences of numbers drawn from a fixed, finite set of symbols. Everything a model ever "sees" is a one-dimensional stream of these symbols, one after another, like beads on a string. Our entire job, in this chapter, is to turn a page of writing into such a stream — and to do it well, because how we do it turns out to matter enormously.

Let us take the most naive approaches first, because their failures are exactly what motivates the clever solution.

Attempt one: one symbol per character. The obvious idea. Let each distinct character — every letter, digit, punctuation mark — be a symbol. "cat" becomes three symbols: c, a, t. Clean and intuitive. But now consider that the model must handle not just English but every script humans write in: Cyrillic, Arabic, Chinese, Japanese, Korean, mathematical notation, emoji, and the thousands of rarer symbols in between. The universal catalogue of these characters, called Unicode, contains around 150,000 distinct code points and grows every year. A vocabulary of 150,000 symbols is workable in principle, but it is unstable — tied to a standard that keeps changing — and it wastes enormous capacity on symbols the model will almost never see. Worse, it still splits common English words into many symbols, which, as we are about to discover, is costly.

Attempt two: work in raw bytes. There is a beautiful, principled alternative. Every piece of digital text, in whatever script, is already stored as a sequence of bytes, using an encoding called UTF-8. A byte is just a number from 0 to 255 — so there are exactly 256 possible byte-symbols, a tiny and permanently fixed vocabulary. UTF-8 spends one byte on common English characters and two, three, or four bytes on rarer ones. It is universal, stable, and elegant. Let each byte be a symbol, and the vocabulary problem vanishes.

To see the ladder of representations underneath a single ordinary word, look closely:

The hidden cost of bytes is length. In UTF-8, an ordinary English word is several bytes long, and a paragraph is thousands. If every byte is a symbol, then the sequence the model must chew through becomes very long indeed. And here we run into a fact that will echo through every later chapter of this book: the machinery that lets a model relate each symbol to every other symbol grows quadratically with sequence length. Double the number of symbols and you roughly quadruple the work. Sequence length is the single most expensive resource a language model has. Spending it one byte at a time is ruinous.

So we are caught between two pressures, and naming them precisely is the key to everything that follows.

Part III — The machine builds its own alphabet

Now comes the idea at the heart of this chapter, and it is genuinely lovely. We are not going to hand the model a vocabulary. We are going to let it grow one from the data, greedily, by noticing which combinations of symbols happen most often and promoting them to symbols in their own right.

The method is called byte pair encoding, or BPE, and once you see it you cannot unsee it. Start from the humble byte vocabulary — 256 symbols, one per possible byte. Now run through the entire clean corpus and ask a single question: which pair of adjacent symbols occurs most frequently? In English text the answer, early on, is something like the pair t followed by h. So we do the obvious, audacious thing: we invent a brand-new symbol — call it token number 256 — that means "th", and we replace every adjacent t,h in the corpus with this single new token. The corpus just got a little shorter, and our vocabulary just got one symbol larger.

Then we do it again. With "th" now a single symbol, perhaps the most common adjacent pair becomes "th" followed by e — so we mint token 257 meaning "the". Again the corpus shrinks; again the vocabulary grows. And again, and again, tens of thousands of times, each new symbol built from two older ones, each merge chosen purely because the data made that pair common.

When this process halts — for GPT-4's tokenizer, at a vocabulary of 100,277 symbols; for its successor GPT-4o, closer to 200,000 — you are left with something remarkable. The most common English words are each a single symbol. Common word-fragments like "ing", "tion", "pre" are single symbols, so even a word the tokenizer has never seen can be assembled from familiar pieces. And genuinely rare strings — an unusual surname, a chemical name, a snippet of code — dissolve into several small tokens, or in the limit, back into individual bytes. Nothing is ever un-representable, because at the very bottom the byte layer can always spell anything out. The scheme is, to use the technical words, lossless and reversible: you can always reconstruct the exact original text from the tokens, byte for byte.

These learned symbols are what we call tokens, and from here on they are the true units of everything. Not words. Not letters. Tokens — the alphabet the machine assembled for itself, one greedy merge at a time.

Part IV — Looking the tokenizer in the eye

Diagrams and prose can only take intuition so far. The thing that finally made tokenization click for me — and for nearly everyone I have taught it to — was seeing a real tokenizer chew on real text, live. So I am going to ask you to stop reading for a few minutes and go do exactly that.

The tool I send everyone to is Tiktokenizer. Open it, choose a model such as GPT-4o, and type into the box. As you type, the text is split into coloured tiles — one per token — with a running count and, if you look, the integer ID of each token. Type your name. Type a sentence. Type a paragraph of a clinic letter. Watch where the cuts fall. It is quietly mesmerising, and it will surface a series of facts that no amount of reading prepares you for. Let me walk you through the ones that matter most, because each one is a lesson in disguise.

Lesson one: the boundaries are not where you expect. Type tokenization and you may find it is not one token but two or three — perhaps token + ization. The tokenizer has no notion of "words." It only knows the fragments its merges happened to build. Common words are whole; longer or rarer ones fracture along the seams of frequency, not the seams of meaning.

Lesson two: the space is part of the word. This one surprises everyone. In the tokenizer's eyes, world and world — the second with a leading space — are different tokens with different ID numbers. The space travels attached to the front of the word that follows it. It makes sense once you see it: in real text, words are almost always preceded by a space, so " world" is far more common than a bare "world", and BPE duly gave the spaced version its own symbol. But it means the model's internal notion of a word includes its leading whitespace, which is not how any human thinks about language.

Lesson three: capitalisation makes a different symbol. Hello, hello, HELLO, and Hello are, as far as the tokenizer is concerned, four unrelated symbols. The model has to learn from scratch that they are related — that the capitalised form at the start of a sentence means the same thing as the lowercase form mid-sentence. Nothing about the tokens tells it so. This is our first glimpse of a recurring theme: the tokenizer hands the model a set of arbitrary symbols and forces it to rediscover, statistically, the relationships that are obvious to us.

Lesson four: numbers are a mess. Type 127 + 677 = 804 and watch what happens to the digits. You will very often find the numbers carved into ragged pieces — 127 might be one token while 677 splits into 67 and 7, and 804 into 80 and 4. There is no consistent "one token per digit" or "one token per number" rule; the cuts fall wherever the training frequencies happened to put them. Hold on to this observation. It is, as we will see in a moment, the reason a system that can write a sonnet can also insist that 9.11 is larger than 9.9.

Lesson five: not all languages are equal. Paste an English sentence and count the tokens. Now paste its translation into a language that was thin in the training data — Swahili, say, or Amharic — and count again. The second will use noticeably more tokens to say the same thing, sometimes two or three times as many. The tokenizer's merges were learned from a corpus dominated by English, so English got the efficient single-token words while other languages were left in smaller, more expensive pieces.

Part V — Why the disassembly explains the machine

We now arrive at the payoff, the reason I insisted we spend a whole chapter on what looks like plumbing. A great many of the notorious, widely-mocked failures of language models are not failures of intelligence at all. They are direct, predictable consequences of the fact that the model never sees letters — it sees tokens. Once you hold that fact firmly, a whole category of mystery evaporates.

Consider the famous one: how many times does the letter "r" appear in "strawberry"? Models have stumbled on this for years, and every time they do, someone declares that artificial intelligence is a fraud. But look at what we now know. To the model, "strawberry" is not a row of ten letters. It is two or three tokens — perhaps straw and berry. The individual letters are welded inside those tokens, invisible and inaccessible. Asking the model to count the r's is like asking you to count the brushstrokes in a painting you are only allowed to view from across the room. The information has been compressed away at the very first step. The wonder is not that it sometimes miscounts; the wonder is that it manages as often as it does, by having memorised, statistically, facts about its own tokens.

The model does not read the way we read. It never meets the letter. It meets the token — and a token is a wall between the machine and the fine grain of the word.

The same lens clarifies the arithmetic troubles. We saw in Tiktokenizer that numbers fracture into inconsistent pieces. A model asked to add two numbers is therefore not manipulating digits in orderly columns the way a child is taught to; it is pattern-matching over lumpy, irregular tokens whose boundaries bear no relation to place value. That such systems can do any reliable arithmetic is a testament to how much structure they extract despite the tokenizer, not because of it. And it is precisely why serious systems now hand arithmetic off to a calculator tool rather than trusting the raw model — a theme we will return to when we discuss tools and agents.

There is even a genre of outright bizarre behaviour that traces to tokenization: rare tokens that were minted during the vocabulary-building phase but then barely appeared in the actual training text. These "glitch tokens" — famous examples were dug out of early GPT models — are symbols the model possesses but was never taught to use, and prompting with them can produce strange, evasive, or nonsensical output, like pressing a key on a piano that was installed but never tuned. It is a small, eerie reminder that the vocabulary and the training are two separate steps, and that a symbol's mere existence does not guarantee the model knows what to do with it.

Part VI — From tokens to the machine

Let us close by placing this chapter in the arc of the book. We began with the open internet and refined it, filter by filter, into a clean corpus. We then confronted the problem that a neural network reads only sequences of symbols, weighed the naive options, and arrived at byte pair encoding — the method by which the machine grows its own alphabet of tokens, balancing vocabulary size against sequence length. We looked a real tokenizer in the eye, and we saw how its quirks ripple outward into the model's most-mocked failures.

Everything from here on operates on tokens. When you read, in later chapters, that a model has a "context window" of, say, 128,000 — that number is counted in tokens, not words or characters, which is why the efficiency of tokenization directly determines how much real text the model can hold in mind at once. When we build the prediction machinery, its input will be a sequence of token IDs and its output will be a probability spread across the whole token vocabulary — "given these tokens, which token comes next?" The tokenizer is the lens through which the model views all of language, and, as with any lens, its particular distortions shape everything seen through it.

If you would like a preview of where these tokens are headed — the vast machine they are about to enter — there is a beautiful interactive visualiser that renders a working language model in three dimensions and lets you walk through it, stage by stage, watching the numbers flow. Scroll all the way to the bottom of that machine, to where everything begins, and you will find our old friends waiting: a row of token IDs, the raw input, the grain of language from which all the apparent magic upstream is eventually built. I would not open it just yet — much of it will look like beautiful nonsense until we have built up to it together — but bookmark it. By the final chapter, every stage in that visualisation will be something you understand from the inside.

For now, sit with the central surprise of this chapter, because it is the seed of everything: a language model does not read our language at all. It reads a language it built for itself, out of the frequencies of our writing, one greedy merge at a time. Before it is a mind, or a tool, or a threat, or a marvel, it is a reader of tokens. And a token, we now know, is not a word. It is the grain into which we ground our words so that a machine could swallow them.

What did we lose in the grinding — and what, against all reasonable expectation, survived it? That question is the whole of the next chapter.

— Neal