目錄
This article reflects information available as of August 2026. ShieldFont is still an actively developed open-source project.
There has never been a simple and reliable solution for content creators who do not want their online writing scraped at scale and used to train AI. robots.txt can express a site owner’s preference not to be crawled, but whether a crawler respects it still depends on the crawler. Server-side tools such as Cloudflare can directly restrict specific crawlers, but they require website-level configuration and cannot guarantee that every form of data collection will be blocked. ShieldFont, released publicly in late July 2026, takes a completely different approach: instead of preventing crawlers from taking the article, it makes the text they retrieve different from what human readers actually see. The project’s own positioning is also explicit: ShieldFont is not an unbreakable lock, but a friction mechanism designed to increase the cost of large-scale scraping.
It takes advantage of a very ordinary difference in how web content is processed. Readers see text after the browser renders it with a font, while many text crawlers process the raw strings stored in the HTML. ShieldFont first replaces some important words in the HTML with other English words that still fit the grammar, then uses substitution rules inside an OpenType font to display the author’s original text on screen. When the page is opened normally, the article appears unchanged; a system that only retrieves the HTML receives a version that remains reasonably grammatical but has shifted in meaning. The design is interesting, but it also introduces a long list of trade-offs involving SEO, accessibility, copy and paste, and reversibility. At this stage, it is better viewed as an experimental protection mechanism for specific types of content rather than a solution that an ordinary blog should deploy across an entire site.
How Does ShieldFont Work? Humans See the Original Text While Crawlers Receive Different HTML
ShieldFont Replaces the HTML Text First, Then Uses an OpenType Font to Restore What Humans See
ShieldFont’s core consists of an Encoder, a substitution dictionary, and a custom font. Before an article is delivered to the browser, the Encoder modifies the original text according to the substitution dictionary—for example, replacing one noun with another noun. The HTML that reaches the browser therefore already contains the modified version, and the downloaded ShieldFont font then uses OpenType substitution rules to render those replacement words using the glyphs of the author’s original text. The result is that the same HTML effectively produces two versions of the content: crawlers that parse the text directly read the substituted words, while humans using a normal browser see the author’s original wording.
This detail also makes the integration method important. The officially recommended React component performs the encoding on the server side or at build time so that the original plaintext is never sent to the browser. If a developer first sends the original article to client-side JavaScript and only then transforms it in the browser, a crawler may still recover the unprotected original from the JavaScript bundle. ShieldFont therefore specifically warns that genuinely protected text must not be sent to the frontend in readable form. For WordPress, Wix, Squarespace, and other sites without a custom build process, the project provides a workflow in which the text is first transformed through the Encoder and then displayed with the ShieldFont CSS font.
Why Not Turn the Entire Article into Gibberish?
The current v18-alpha version of ShieldFont does not scramble every word. According to the white paper, it replaces an average of about 24.4% of all words. If the calculation is limited to content words—nouns, verbs, adjectives, and adverbs that carry most of the meaning—the replacement rate is about 45.8%. Articles, prepositions, conjunctions, and many common function words are largely preserved, because replacing too many of them would quickly make the text look unlike normal English and make it easier for data-quality filters to discard it immediately.
The substitution process is also more sophisticated than simply “replace a noun with another noun.” ShieldFont uses around 250 grammatical pools that take into account part of speech, semantic category, concreteness or abstractness, singular or plural form, verb transitivity, verb inflection, and adjective degree. For example, a plural abstract noun related to communication is ideally replaced with another word from the same grammatical and semantic category rather than with a random noun. Replacement candidates also exclude synonyms, antonyms, and overly similar words. The goal is for the sentence to continue looking like English while no longer carrying the same meaning as the original. The current dictionary contains roughly 12,000 substitution pairs.
That balance is important. If too little is changed, a crawler can still preserve most of the original meaning. If too much is changed, the content may be classified as low quality and filtered out before it ever reaches a training dataset. ShieldFont is trying to position the text between those two extremes: not obvious gibberish, but an article that still resembles normal English while its details begin to diverge from the original.
Does ShieldFont Actually Work? The Official Data Shows That Meaning Changes, Not That Models Are Guaranteed to Be Poisoned
55.8% of News Paragraphs No Longer Express the Same Factual Claim
The ShieldFont team tested the current v18 dictionary on four categories of text: news, general web pages, fiction, and older fiction. The evaluation measured whether the original and encoded text still supported the same factual claim. The results showed bidirectional NLI failure rates of 55.8% for news, 51.9% for general web content, 34.5% for fiction, and 31.1% for older fiction. In other words, the original and encoded versions could no longer mutually support the same claim. As a control, replacing the same number of words with genuine synonyms produced a failure rate of only about 2.1%.
| Test Content | No Longer Preserves the Same Claim After ShieldFont |
|---|---|
| News | 55.8% |
| General web content | 51.9% |
| Fiction | 34.5% |
| Older fiction | 31.1% |
| Synonym-replacement control | About 2.1% |
What these numbers support is the conclusion that ShieldFont can significantly alter the meaning of text obtained by a crawler, especially for news and general web content. They do not directly prove that a large model trained on such data will necessarily perform worse. The ShieldFont team explicitly draws this boundary in its README: it does not currently claim that encoded text will reliably pass every data-quality filter, nor does it claim to have proven that training on the encoded content will damage a real large language model.
Most ShieldFont Text Is Actually Rejected by Quality Filters First
This is one of the most important points to add to the original discussion. ShieldFont does not mainly work by “secretly slipping incorrect text into a model.” When the team tested encoded content using the FineWeb-Edu quality-filtering approach, 99.0% to 99.8% of ShieldFont-processed text was rejected by the filter. Put another way, only a small fraction of content that would originally have passed the quality checks remained after ShieldFont processing. Among the text that did survive filtering, the team estimated that about 19.4% of the token budget carried altered semantics.
That makes ShieldFont’s practical effect closer to a two-path mechanism: some content becomes low-quality enough that it never enters a training dataset, while some of the text that remains no longer expresses what the author originally wrote. The project itself describes this as a form of collective defense, because one article has essentially no influence inside a dataset containing trillions of tokens. What it is really trying to increase is the processing cost faced by large-scale collectors when many sites use different substitution rules.
ShieldFont’s Biggest Limitation: It Can Actually Be Decoded
The Font Itself Is the Decoding Table, So a Single Website Is Not Especially Hard to Reverse
ShieldFont is very open about this problem. In order for the browser to restore the replacement text to the original visual output, it must receive the corresponding font file, and the glyph substitution rules inside that font inherently contain the information required to decode the text. The development team even tested this attack itself and was able to recover all 11,962 substitution pairs from the official font without errors.
ShieldFont is therefore not cryptographic protection, nor is it suitable for defending against an attacker specifically targeting one website. The project provides custom mapping support so that large-scale crawlers cannot simply prepare one copy of the official dictionary and decode every ShieldFont site in bulk. If each site uses a different mapping, the crawler must first identify the font, retrieve the correct file, analyze the substitution rules, and then decode that specific website. What ShieldFont adds is workload, not an impenetrable barrier.
OCR Can Directly Bypass Font Substitution
If a page is normally rendered, captured as an image, and then processed through OCR or a vision model, the result is the same original text that a human sees on screen. ShieldFont does not deny this bypass. Instead, it explicitly treats OCR as the current lower bound on the cost of defeating the protection. The underlying assumption is that large-scale crawlers can collect billions of pages because retrieving HTML is cheap; if they instead need to launch a browser for every page, render it, capture it, and run visual recognition, both cost and processing time rise.
A more precise description of ShieldFont is therefore economic defense rather than technical impossibility. It does not need OCR to become impossible. It only needs “processing the entire public web this way” to become less economically attractive. There is currently no independent data showing how large that cost increase would need to be before major AI companies would abandon the approach.
Does ShieldFont Affect SEO? Protected Text Is a Poor Fit for Search-Driven Content
Search Engines Also See the Replacement Text
ShieldFont’s official SEO guidance is direct: search engines, like ordinary text crawlers, encounter the replacement content in the underlying page, so protected sections may be indexed using decoy words instead of the words the author actually wants to rank for. The project explicitly recommends against shielding all Marketing Pages that need Google rankings. Instead, it suggests reserving ShieldFont for content that does not depend on search visibility, such as paid articles, archives, manifestos, or other material where reducing AI-training usefulness matters more than organic search traffic.
For bloggers, this means ShieldFont and content SEO are inherently in tension, but it does not have to be an all-or-nothing decision. ShieldFont can be applied block by block, and the React version also provides <NonShield> so that headings, navigation, captions, and other elements can remain as normal text. One practical strategy would be to leave H1s, H2s, summaries, product pages, and primary search-targeted content untouched, while applying ShieldFont only to specific long-form or member-only content that does not rely on organic search.
However, if a website’s main revenue source is Google organic traffic, replacing an entire SEO article with ShieldFont still makes little sense. For this type of site, robots.txt, AI crawler controls, Cloudflare, and other server-layer tools at least do not actively turn the body text that search engines need to read into a different version.
ShieldFont Has Improved Its Screen Reader Support, but It Still Does Not Meet WCAG
The Latest React Version No Longer Simply Makes Screen Readers Read the Decoy Text
One of ShieldFont’s earliest and most direct problems was that screen readers, like crawlers, processed the underlying text and therefore read the replacement version aloud to visually impaired users. The recommended React <Shield>component now includes a beta Accessibility Layer. It first hides the substituted body text using aria-hidden, then provides a separate encrypted copy of the real text. Screen reader users can access a button available only to assistive technologies to unlock the original text, after which the browser spends a few additional seconds performing the required computation. The project says it has tested this with VoiceOver and automated screen reader testing, while NVDA is also included in CI.
That does not mean the accessibility problem has been solved. ShieldFont’s README explicitly acknowledges that even with all Accessibility features enabled, protected blocks still do not conform to WCAG 2.2 SC 1.3.1. Readers using assistive technology must also wait several additional seconds, and their path to obtaining the content differs from that of ordinary readers. The project directly recommends that websites legally required to meet accessibility standards, or sites that claim WCAG compliance, should not use ShieldFont on the relevant content.
Ordinary WordPress and static websites need to be even more careful: the official React package automatically includes this alternative layer, but sites using only the CDN font and manually encoded text must build the Accessibility Layer themselves. This is one reason ShieldFont is currently not an accessibility-safe solution that can be completed simply by pasting in a CSS rule.
Copying and Pasting Also Produces the Replacement Text
There is another limitation that may be even more noticeable in everyday use than SEO. If a reader selects content on a ShieldFont-protected page and copies it, the clipboard receives the replacement words that actually exist in the HTML rather than the original text displayed on screen. In other words, someone trying to quote an article, save it to a note-taking app, paste it into a translation tool, or send it to ChatGPT may receive the modified version instead.
The project therefore explicitly warns against using ShieldFont on content that readers need to Search, Quote, or Cite. Academic articles, educational materials, government information, medical information, and essential service content all require particular caution because of this trade-off.
Does ShieldFont Support Chinese? For Now, It Only Supports English
ShieldFont currently supports only English. The project provides three primary English mappings—alpha, beta, and gamma—each containing roughly 12,000 word pairs, along with a maxhide version that uses a higher replacement rate. Text in other languages is left unchanged, so even if an entire Chinese-English mixed page is wrapped in ShieldFont, only the English portions are actually protected.
This is a very direct limitation for Chinese-language blogs. Supporting Chinese is not simply a matter of translating the English replacement dictionary, because ShieldFont’s mechanism depends on language-specific features such as part of speech, semantic classification, singular and plural distinctions, and verb morphology. The project itself has said that additional language versions would require native speakers who understand the language to redesign the substitution pairs. For now, Chinese-language sites can at most monitor the technology’s development; they cannot yet treat it as a deployable protection tool for Chinese articles.
Twitch Adds an AI Training Opt-Out, but It Is Still Unclear How Much Past Content Was Used
ShieldFont is a creator-controlled protection method applied at the website level. In the same week, Twitch introduced a different approach from the platform side. On August 12, 2026, Twitch added a Training for Generative AI setting that allows channel owners to opt out of having Streams, VODs, Clips, Stream Chats, and text and images on their channels used to train Amazon’s future generative AI models. The setting is located in the Security and Privacy section of the account. Turning it off does not affect other Twitch features that use AI, such as AutoMod, recommendations, or captions.
The most controversial detail is that the setting is opt-out rather than opt-in. During an official livestream, Twitch Chief Product Officer Mike Minton was asked why users were not required to actively opt in. His answer was direct: if people had to choose to participate, almost nobody would.
Another sentence from the earlier draft—that “Twitch confirmed content had been used to train Amazon AI for years”—should not be retained as an established fact. Twitch’s current explanation explicitly discusses opting out of future training, but when viewers asked whether older videos had already been used by Amazon, Minton said he did not know which Twitch data Amazon had previously used for model training. What can currently be confirmed is that the platform permits Amazon to use content for generative AI training and now provides a new opt-out mechanism. Official statements do not establish how many years of past data were used or which specific content entered which models.
The U.S. Government Is Also Reconsidering Open-Weight Models, but the Policy Change Is Still Unpublished
In June 2026, the White House signed an executive order establishing a voluntary Frontier Model safety evaluation framework that allows qualifying models to be provided to the federal government for testing up to 30 days before release. The implementation direction announced in early August initially focused mainly on closed frontier models, while open-weight models were not subject to the same pre-release testing process.
On August 12, WIRED cited White House officials and people familiar with the matter as saying that the framework is expected to be revised and that open models may eventually be brought into the same testing regime if they reach capabilities comparable to today’s closed Frontier Models. This remains a media report based on officials’ statements rather than a new rule formally published by the White House. The current framework is still voluntary, and the detailed evaluation standards have not been made public.
Putting ShieldFont, Twitch, and the White House policy discussion in the same article reveals three different levels of response, but they should not be described as a unified system that has already taken shape. ShieldFont is a creator-side attempt to increase the cost of data collection, Twitch is a platform-level opt-out mechanism, and the White House discussion concerns whether increasingly capable AI models should undergo safety evaluations before release. The only common thread is that the question of who gets to decide how data and models are used is gradually becoming not only a technical issue, but also a product and policy issue.
What Can Content Creators Do Now to Reduce the Risk of AI Training Scraping?
First, Check Whether the Platform Itself Provides an AI Training Opt-Out
This is currently the lowest-cost step. Twitch also shows why these settings may not be disabled by default and may not appear in the most obvious part of the interface. On platforms where you regularly publish text, photos, video, or audio, first check Privacy, AI, Data Usage, Security, and similar settings to determine whether content may be used for generative AI training and whether an opt-out exists. Policies differ across platforms and may also vary by region, so these settings need to be reviewed individually rather than assuming every service follows the same rules.
For Self-Hosted Sites, Start with robots.txt and Server-Side Controls Before Considering ShieldFont
ShieldFont itself explicitly recommends that it should not replace robots.txt, Cloudflare, Akamai, or ordinary security controls. robots.txt at least provides a clear declaration that a site does not want specific crawlers to access certain content, while server-side tools can directly block known User-Agents, IP addresses, or other scraping behavior. ShieldFont is better positioned outside those measures as an additional experimental layer that increases the cost of unauthorized mass scraping.
This sequence also makes more sense from a risk perspective. Directly preventing someone from obtaining the data is generally cleaner than deliberately allowing them to obtain an altered version. ShieldFont’s additional value only appears when blocking can be ignored or bypassed: even if the content is taken, the crawler does not receive the original text.
Do Not Use the Same Protection Strategy for SEO Articles, Member Content, and Original Creative Work
If a site depends on search traffic, it is not suitable to replace the entire site’s body content with ShieldFont. A more plausible strategy is to keep the homepage, category pages, search entry points, SEO articles, and commercial pages normally indexable, while separately protecting member-only articles, archives, or selected original works that do not need Google rankings and that you do not want scraped at scale. ShieldFont supports block-by-block application, so technically the entire page does not need to be protected at once.
For Chinese-language websites, the current decision is even simpler: ShieldFont cannot meaningfully protect Chinese content yet, so there is no reason to sacrifice SEO or accessibility for it today. A more practical approach is to first review AI training opt-outs on the platforms you use, configure robots.txt and CDN／WAF controls, and then watch whether a usable Chinese mapping is eventually developed.
The most interesting thing about ShieldFont is not that it invents a way to make articles “impossible for AI to scrape.” The project openly acknowledges that its fonts can be fully reverse-engineered, OCR can bypass the system, and SEO and Accessibility come with explicit costs. The genuinely new idea is that it changes the goal of protection from “completely prevent copying” to “make large-scale, cheap, indiscriminate copying a little more inconvenient.”
Whether that approach will actually change how major AI training datasets are collected remains unproven. The effect of a single website is also very limited. The ShieldFont team itself acknowledges that its real bet is on collective defense created when large numbers of sites adopt different mappings. For content creators today, the more reasonable way to view it is as an experimental new tool rather than a replacement for robots.txt, server-side blocking, licensing terms, or platform opt-out mechanisms.
FAQ
ShieldFont first replaces some important English words in the HTML on the server side or during the build process, then uses OpenType substitution rules in a custom font to render the original wording in the browser. Normal readers see the author’s original text, while crawlers that only retrieve the HTML receive the substituted version.
The current v18-alpha version replaces an average of about 24.4% of all words. If the analysis is limited to content words such as nouns, verbs, adjectives, and adverbs, about 45.8% are replaced. Replacement candidates are organized into around 250 grammatical pools based on part of speech, semantics, singular or plural form, verb morphology, and other conditions.
Not reliably. OCR can read the original text after the page is rendered, and the font file itself can be analyzed to reconstruct the substitution mapping. ShieldFont’s goal is to increase the identification, rendering, and decoding costs required for large-scale automated scraping rather than to make it permanently impossible for a targeted attacker to obtain the article.
Yes, for protected content. ShieldFont states that search engines can read the substituted HTML and may therefore index decoy words. The project recommends not protecting Marketing Pages that need Google rankings and instead using ShieldFont selectively on content that does not depend on search traffic. ShieldFont can be enabled block by block rather than across an entire site.
Not currently. The React version includes a beta screen-reader alternative that allows assistive technologies to access the real text, but the project still explicitly states that Shielded Blocks do not conform to WCAG 2.2 SC 1.3.1. Websites that are legally required to meet Accessibility standards should not apply ShieldFont directly to the relevant content.
No. The current mappings only process English, while text in other languages remains unchanged. Building a Chinese version would also require more than translating the English dictionary; it would require redesigning substitution rules around Chinese grammar and semantics. For now, Chinese-language content creators still need to rely primarily on other crawler-control methods.