ShieldFont poisons AI scrapers with nothing more than a font

August 2026. Two designers, Isaque Seneda and Gabriel Abrucio, published the white paper for ShieldFont, a typeface that renders perfectly readable text to the human eye while serving scrapers a subtly scrambled version of the content, directly in the underlying HTML. The idea fits in one sentence: bots that pull the raw source code get text whose meaning has been altered, and the human reader never notices.

For a self-hoster running a blog, a wiki or documentation — a site whose value is the text itself — it is the first technical defense that depends on neither the good will of crawlers nor an application firewall.

robots.txt is not enough anymore

Publishers who want to keep their content out of AI training still reach for robots.txt, with directives targeting GPTBot, ClaudeBot, Google-Extended or CCBot. The problem is structural: those directives are honorific. A crawler that chooses to ignore them can pull the content with zero technical consequence, and several large-scale scraping actors do so openly.

That is exactly the gap ShieldFont aims to fill. The authors put it in writing in the white paper: “Being discoverable does not mean consenting to AI training.” Their stated goal is not to block, but to make collection less useful and more costly when consent is not respected.

A ligature that swaps the word, not the letter

The mechanics rest on an old typographic device: ligatures. Normally a ligature replaces a letter pair with a more readable glyph. ShieldFont hijacks the mechanism to replace whole words with other words of the same part of speech but a completely different meaning — trading “horse” for “potato,” for instance. The substitution only happens when the font engine draws the page on screen, so a scraper that downloads the source text gets an altered version the end user never sees.

After three months of refining the dictionary, the authors have nearly 12,000 common swappable words, with three possible mappings per word to complicate detection. A publisher can encode their own mappings and vary them paragraph by paragraph. On average, ShieldFont replaces 24.5% of a page’s words — including 45.8% of “content words” — and muddles the meaning of 31 to 56% of passages depending on the corpus.

The measurements are unambiguous. Tested against six public scraper pipelines, ShieldFont gets more than 90% of pages that would normally pass quality filters rejected. Of the small fraction still accepted, nearly 20% of the words are what the authors call “training-time garbage”: correct, well-spelled English that asserts nothing true. Both outcomes favor the publisher — dropped, the scraper did not get your work; kept, it got something wrong.

Deployment is three lines

Integration is trivial for a static self-hosted site: declare the font, apply it, done. No server dependency, no JavaScript, nothing to maintain.

@font-face {
  font-family: "ShieldFont";
  src: url("/fonts/shieldfont.woff2") format("woff2");
  font-display: swap;
}

body {
  font-family: "ShieldFont", sans-serif;
}

That simplicity is the killer argument for a self-hoster: the defense is static, served from the same server as the rest of the site, with no additional point of failure and no infrastructure cost. It stacks with existing defenses — robots.txt, Cloudflare rules, user-agent range blocking — without replacing any of them.

What the font breaks along the way

The tradeoff is real and must be accepted. The altered HTML text disrupts search engines, screen readers, copy-paste and translation tools. For a site that lives on organic traffic or must stay accessible to everyone, that is a direct cost: the content you are defending becomes less usable by the very machines that also serve your readers.

The technical limit is just as clear. Any page readable by a human can be correctly interpreted by a scraper that renders the full page and runs optical character recognition (OCR) on the output. That countermeasure is expensive: third-party scraping-tool API costs suggest such pre-rendering runs five to thirteen times the price of simply pulling HTML. That is precisely the authors’ target — indiscriminate scraping at the scale of billions of pages, not a determined adversary going after one site.

The authors also own the cat-and-mouse nature of it: the more implementations of “show one thing to humans, another to machines” exist in the wild, the harder it is for scrapers to learn to bypass them all.

Where ShieldFont fits in the arsenal

ShieldFont does not stand alone, and it replaces none of the classic tools. robots.txt remains the first line — cheap, and widely ignored. Network blocking of known user-agent ranges (GPTBot, ClaudeBot, CCBot) works against crawlers that identify themselves, but not against those that lie about who they are. Rate limiting and application firewalls (Cloudflare, Fail2ban) stop mass abuse, not targeted collection. Terms of use and copyright give you a basis for a complaint, but no technical protection.

ShieldFont occupies a slot the others leave empty: it degrades the value of whatever is collected, even when collection succeeds. It is a last-resort defense that acts after the others have failed. For a self-hosted site, it combines naturally with network blocking (which cuts the bulk of the traffic) and robots.txt (which documents your intent, which matters in a dispute).

The white paper’s example makes the point vividly: after substitution, a sentence about “a very interstate southern engineer with a sofa car” is grammatically correct but means nothing. That is exactly the kind of text that, ingested at scale, dilutes a training corpus without ever tripping a quality alarm.

For self-hosters who also care about search visibility, there is a middle path: apply ShieldFont to a subset of pages — long-form essays, technical notes, anything whose audience arrives directly rather than through search — while leaving landing pages and index pages untouched. It is not all-or-nothing. The same selective approach lets you keep copy-paste intact on documentation where readers copy commands, and apply the font only where the prose itself is the asset.

The honest framing is defense in depth: none of these tools alone stops a determined scraper, but each one raises the cost of ignoring you. Deployed together — a strict robots.txt, network blocking of the obvious crawlers, and ShieldFont on the pages whose text is the asset — they turn your self-hosted site from an easy scrape into a project not worth the compute.

Verdict

ShieldFont is neither absolute protection nor a substitute for negotiating rights. It is a cost raiser: it turns nearly free collection into a process five to thirteen times more expensive, and it silently poisons the datasets of those who persist.

The decision turns on one question: what is your site for? If you self-host a blog, a wiki or documentation whose value is the text, your audience reads you directly, and you can absorb degraded search and accessibility, then deploying ShieldFont is rational — three lines of CSS to make your content substantially less useful to scrapers. If your site depends on organic traffic, copy-paste, or readers using screen readers, walk away: the cure would cost you more than the disease, and the classic defenses remain — a strict robots.txt, network blocking of known crawlers, and terms of use that give you legal standing to complain.

The point is not the font. It is the principle it materializes: creator consent can be defended technically, not just declared. For a self-hoster who owns their content as much as their machine, that is one more tool in a box that held precious few.

References

• ShieldFont, white paper, “A practical opt-out from unauthorized AI training”, shieldfont.org/white-paper, August 2026.
• Ars Technica (Kyle Orland), “The web’s newest weapon against AI scrapers is a font”, August 2026.
• selfh.st, Self-Host Weekly, August 14, 2026, Newswire section.