Frontend · JavaScript · HTML

Every Front-End Anti-Copy Trick, Ranked by How Fast It Breaks

By AsherJ · Jul 8, 2026

Read original on juejin.cn ↗ Google Translate ↗ Alt translation

Copy protection on the web is a cost-benefit negotiation, not a technical lock. Understanding exactly where each defense fails prevents teams from over-engineering solutions that degrade accessibility and SEO while still being trivial for a motivated scraper to bypass.

Summary

CSS user-select and disabled context menus stop only the least technical visitors; opening DevTools and deleting a rule or toggling a browser setting defeats them in seconds. JavaScript copy-event interception and transparent overlays add a trivial extra step—registering a capture-phase listener or removing a DOM node. The more pragmatic approach, used by Zhihu and The New York Times, allows copying but silently appends a source attribution to the clipboard, trading absolute prevention for provenance tracking.

Canvas rendering and custom-font glyph shuffling represent the hardest tier. Canvas leaves no text in the DOM, killing SEO and accessibility, while font obfuscation maps typed characters to unrelated glyphs so pasted output is gibberish. Both still fall to OCR or font-table analysis, just with higher effort.

An interactive attack-defense simulator lets readers stack protections and choose an attacker profile—from casual user to professional scraper—to see simulated bypass times. The consistent result: every defense is breakable; the only variable is how much friction it adds relative to the value of the content.

Takeaways

— CSS user-select: none and disabled context menus block only users who never open DevTools; both are undone in under ten seconds.

— Intercepting the copy event via JavaScript is neutralized by registering a capture-phase listener that calls stopImmediatePropagation.

— A transparent overlay div over text is removed by deleting the element or setting pointer-events: none in DevTools.

— Clipboard content replacement appends a source line to copied text—effective for attribution, not for preventing extraction.

— Canvas-rendered text contains no DOM nodes, so crawlers see nothing, but it destroys SEO, accessibility, and performance.

— Font mapping obfuscation shuffles character-to-glyph mappings so pasted text is garbled; it can be reversed by analyzing the font's cmap table or using OCR.

— An interactive simulator demonstrates that every defense fails given enough attacker motivation; the only meaningful metric is bypass cost.

Conclusions

The taxonomy from CSS to font obfuscation maps directly to attacker sophistication, making it a practical threat-modeling exercise rather than a security checklist.

Clipboard attribution is a category error in the anti-copy discussion—it solves a business problem (provenance) while the other techniques attempt a technical one (prevention) that is unsolvable.

Font obfuscation's per-user, per-chapter mapping variation is the closest the web gets to a DRM-like scheme, yet it still collapses against a determined adversary with OCR.

Concepts & terms

Font mapping obfuscation

A custom web font where internal character codes are deliberately mismatched to displayed glyphs, so copying text from the page yields garbled characters while the screen shows readable words.

Canvas text rendering

Drawing text onto an HTML Canvas element via fillText, which produces pixels on screen but leaves no selectable text nodes in the DOM, blocking conventional text extraction.

Clipboard content replacement

Intercepting the browser's copy event to modify what gets placed on the clipboard, typically appending a source attribution or link to whatever the user selected.

Source: juejin.cn ↗ Google Translate ↗ Backup ↗