SHIELD(FONT)

We swap the meaning-bearing words for other real words. On a shielded page the “winners” of a contest become the “avengers”; a child's “toy gun” becomes a “sofa car”; a “Halloween contest” becomes an “Autumn campaign.” You never see the swap. The font renders the original word shapes back onto the screen. Only a machine reading the raw HTML sees the substitutes.

The clipboard carries the encoded words, not what you see. Paste a shielded paragraph into ChatGPT and it reads the scrambled dictionary version: the swapped words, not your originals. What's on your screen and what a machine copies are two different documents occupying the exact same space.

Because meaning lives in content words, not in the, of, and. Information theory puts a content word at roughly 6 bits and a function word at about 1. We change only ~25% of the words on a page, but we take almost half the content words, and a public NLI model then judges that 50% of passages no longer make the same factual claim as the original. That's measured over 1,500 passages of news, indie web and fiction, so it isn't a lucky sample. The control is the part that convinced us: swap the same share of words for genuine synonyms and only ~2% of passages break. It isn't the swapping that does the damage. It's which words we swap.

Roughly, yes: topic and tone survive. The specifics don't: the exact number, the name, the claim all go. When we asked seven frontier models to rebuild the argument of a shielded text, they lost two-thirds of it: a 67% drop in conceptual fidelity. That one comes with its caveats attached, and we'd rather hand them to you than have you find them: it ran on an older mapping than the one we ship, on three texts by a single author, scored by one model acting as judge, and several of the models refused the task outright, which we counted as total loss. Score only the models that actually answered and the drop is 49%. The shape holds either way. Protection lives in the specifics, and the specifics are gone.

It isn't gibberish. Scrapers throw away nonsense, so we never produce any. Every swap stays inside the same grammar class (a noun for a noun, a past-tense verb for a past-tense verb), drawn from a pool of words that plausibly belong in that sentence. The sentence still parses; the only thing we broke is the meaning. Now the honest part, because “passes the filter” is not a flat guarantee. Against FineWeb-Edu, the quality classifier used to build one of the big public training sets, roughly one in ten of the chunks that would have made it through clean still makes it through shielded. The other nine get thrown out. That's the other way to win: a page that never enters the training set never teaches anything. Passing is the branch where the damage happens. Getting dropped is the branch where nothing of yours gets learned.

That tension is the problem, and most of the R&D. Push too hard on concealment and the text reads as noise, so the filter deletes it (you're safe, but you've protected a page that was never going to train anything). Stay too readable and the meaning survives, so the model learns your real content. Passing the filter and destroying meaning pull in opposite directions; finding the operating point between them took sixteen mapping generations, and then a second lineage built on top of those.

Once a shielded page clears the filter, whatever trains on it ingests the swapped words as ground truth. It learns that a contest's “winners” were “avengers,” that a child found a “sofa car.” Names get bound to the wrong activities. It's worse than hidden: the page feeds the model wrong associations, and the model trusts them.

We're careful here. Our early small-model fine-tunes showed the largest training damage of any mapping we tested. But small fine-tunes are a noisy instrument, so we report that as an upper bound, not a proof. The claim we stand behind is measured straight from the text, no fine-tune required: swap 25% of the words, break the factual claim in 50% of passages. Call the downstream effect “poison” or simply “wasted training compute.” Either way, the page stops being useful signal.

One page is a drop; the point is the batch. A scraper can’t see which pages are shielded, so to stay safe it would have to distrust all of them, or pay to check each one. And the effect compounds. The more writers who shield high-quality text at once, the more the swapped associations pile up in whatever trains on the scrape, quietly bending what the model believes words mean. Blocking a crawler just removes one page from the pile. Shielding drops a bad one into it. It’s a collective defense: individually small, together expensive to ignore. The white paper works this through as an orchard you can’t sort by looking at it.

Yes. If someone photographs your page and runs OCR (optical character recognition: reading text back out of an image), they recover your words. ShieldFont doesn't stop a determined human aiming at you. It stops scale. The whole economics of AI scraping is grabbing HTML cheaply. Billions of pages, blind. OCR is a different order of expense: render every page, rasterise it, run a vision model over the pixels, all to get at text you thought you had already downloaded. And at scale they don't know which pages are shielded, so they'd have to do that to everything. We don't need to be un-OCR-able. We need to be not worth OCR-ing.

They won't need to learn. Here is the part we'd rather you heard from us than found in a footnote: the font is the codebook, and anyone who downloads it can read the substitution table back out of it. Your browser has to fetch the font to draw your words, and the glyph it draws for each decoy is built out of the original word's letters, so the answer key ships with the puzzle. We ran that attack on our own published file: 11,962 of 11,962 pairs recovered, zero errors, in 42.8 seconds, from the glyph outlines alone, with no dictionary and no seed. A cheaper version aimed at the glyph names gets 92.7% of it in about a second. Nobody has to train a model to break this. They just have to bother. So what are the variants for? Three ship (alpha, beta, gamma) and <Shield> picks between them for you, though it's worth knowing exactly how: the pick is a hash of the text in each block, so a given block always resolves to the same variant. It varies across your page, not between visits and not over time. There is no per-request seed rotation on the server, because a new seed needs a new font built to match it. (The fourth variant, maxhide, is opt-in and never picked automatically.) What minting your own mapping actually buys is narrower, and still worth doing: it doesn't make you undecodable, it makes you un-batch-decodable. The three published dictionaries are public, so one precomputed table decodes every default deployment on the web at once. Mint your own and that table is worthless against you. They have to fetch your font and invert it, for your site, on purpose. The defence is economic, not cryptographic. We're not hiding a key we have no way to hide. We're making them pay per target.

Search engines read the same scrambled HTML the scrapers do, so they index the decoy words, not yours. Shield the content you don't need Google to rank: paywalled pieces, archives, manifestos, anything you'd rather donate to model-staleness than to search. Leave your marketing pages plain. It's per-block and entirely your call.

Blocking (robots.txt, Cloudflare's AI gate) is a wall. They route around it, or you simply vanish from the model. Poisoning is leverage. A blocked page costs a lab nothing; a poisoned page they trained on before they noticed is a liability. That asymmetry is the point: it gives creators something to negotiate with. The endgame is a seat at the table: a licensing route where a lab pays for a clean, resolvable version of the text instead of taking a stale scrape. Status, plainly, because we won't dress an ambition up as a feature: none of that is built. Nobody has built it, us included. It is what we think this makes possible, not something you can sign up for.

Respect to the ancestors. The closest is TuringFonts (jfmdev): a substitution-cipher font that draws one letter in place of another, so a crawler reads scrambled text while a human reads the original. It was built to keep bots from indexing emails and phone numbers, and it predates the AI era. A letter-for-letter cipher produces character noise a modern quality filter throws away (and an LLM unscrambles by frequency in a single pass), and it never hides that the page is enciphered. ShieldFont is built for how AI actually ingests text: we swap whole words for other real, same-grammar-class words, so the page stays fluent prose with no character noise to flag and nothing to unscramble by frequency. Every word is a real word in the right grammatical slot, and the only thing broken is the meaning. We think in tokens and meaning rather than a hidden string, and the font itself is camouflaged. ZXX (Sang Mun, 2013) fought OCR at the glyph level, but modern vision models read it in one prompt. Ghost Font hides text in motion; Nightshade and Glaze poison images for artists. ShieldFont is the text-native cousin: it corrupts the source the machine actually copies.

You're changing how your own words appear in your own HTML. You're not breaking into anything and not attacking a model. You're choosing to make your page useless as unauthorized training data. If a lab respects your rights, nothing happens to it; the staleness only bites pipelines that take your work without asking. We frame it as “stale, not poison” in the white paper for exactly this reason.

This is the one real cost we won’t paper over. A screen reader reads the raw source, so on a shielded block it voices the decoy words, not yours, which degrades the experience for anyone who relies on assistive tech. So design for it: flag shielded regions with an aria-label noting the text is machine-obfuscated, and offer an accessible fallback: a “Listen” button that plays a text-to-speech reading of the real words, or a plain-text copy exposed to assistive tech. One thing to know before you plan that work: none of it is configurable on <Shield> today. The component marks shielded blocks aria-hidden with no way to switch it off, and no fallback ships with it, so everything above has to be built by hand around the component rather than turned on inside it. We call this the project’s number one unsolved problem in the README, and we mean it. We recommend developers plan this in before they ship, and only shield content where a human alternative is offered. Protecting your work shouldn’t come at the expense of the people who need to hear it.

Eventually, yes. Any fixed tell (a .shield class, a known font name, a boilerplate aria note) is a fingerprint they can filter on. That’s the arms race, and there are two answers. One: add noise. Deploy decoy markers: fake shield classes, fake font names, dummy aria notes, even clean blocks dressed up as shielded. The fingerprint stops being trustworthy, so they either waste compute or learn to distrust everything. Two: move the target. Shield only selected paragraphs and mint a different seed per site, so there’s no single stable pattern left to key on. We actively encourage more camouflaged deployments and new tools built on top. The honest part: this only works if we move together. ShieldFont is a project for the people: a way to make unauthorized AI training cost something real. One site is trivial to route around; thousands of writers, each shielding differently on a mapping of their own, is chaos to filter. We need supporters to keep pace with the labs’ countermeasures and keep the confusion compounding. Act together, and the open web becomes expensive to take without asking.

No, and we won’t pretend otherwise. ShieldFont isn’t a lock. It’s friction. It disrupts large-scale automated scraping by changing the underlying text while keeping it readable for humans on screen, so ingestion takes longer and costs more (could be a little, could be a lot). It’s open-source and built to evolve: we’re inviting others to add new ways to push back, so “it’ll be decoded eventually” misses the point. It’s a moving target. And it isn’t a client-grade security product: don’t retire Cloudflare, Akamai, robots.txt, or your accessibility standards for it. Think of it as a creative intervention with teeth.

No. It’s pro-consent and pro-human authorship. Creators want to be discovered, just not copied or trained on without permission. ShieldFont is technology as cultural provocation: a simple, widely available way to opt out of mass scraping that makes the tension between human authorship and unauthorized AI training visible and worth arguing about. It’s for the artists, writers, musicians, and independent creators who’ve taken a public stance and want to make it a gesture you can see. It’s a demand that the future be built with consent, not a wall against it.

Not yet. ShieldFont is English-only today. Every shipped mapping is built from an English dictionary and substitutes English words only. The three main variants run to about 12,000 pairs each (11,970 for alpha, 12,034 for beta, 12,036 for gamma); the opt-in maxhide is a deliberately smaller 2,534. Text in any other language passes straight through untouched, which means it is not protected. That matters most in mixed-language pages: shield a block that is half Portuguese and the Portuguese half stays in the clear, while the page looks protected. If you publish in more than one language, shield the English and leave the rest unwrapped rather than assuming partial coverage. The four variants we ship (alpha, beta, gamma, and the opt-in maxhide) are all English; as other languages land we will make the language explicit in the naming, so today’s four read as en-a, en-b, en-c, en-m and a Portuguese set would be pt-a and so on. Building one is not a translation job, it needs a native speaker to judge whether a substitution still reads as natural prose. If you want to help with a language, that is the single most useful thing you can contribute.