A browser-based clipboard viewer that runs entirely client-side is the most practical online API alternative for developers who need to inspect clipboard text without writing or hosting their own Clipboard API integration. The web Clipboard API, standardized by the W3C, requires HTTPS, a focused page, a user gesture, and explicit permission — and even then, browsers can refuse the call based on user settings, enterprise policy, or embedded-page restrictions. Building a debug helper around that API means handling permission denials, supporting both read and paste fallback paths, and ensuring your helper does not silently exfiltrate whatever users copied. A local-first viewer sidesteps those concerns: you read the clipboard through the standard API when the browser allows it, paste into a text box when it does not, and watch character counts, Unicode code points, UTF-8 byte length, line breaks, word-like tokens, whitespace, and JSON validity update as you type. The Clipboard Viewer follows that exact pattern — everything stays in the current browser tab, no clipboard text is uploaded, and analysis happens immediately.
When a custom clipboard API isn't worth writing
Most clipboard problems are invisible. A value that looks correct on screen may contain a trailing space, a tab mixed with spaces, a stray CR on macOS, a hidden U+200B zero-width space, or a supplementary-plane emoji that occupies two UTF-16 code units. When a regex fails in production, an environment variable refuses to load, or a database field rejects the same string you pasted, the first instinct is to inspect the raw bytes. Wiring that inspection against the W3C Clipboard API means a small codebase plus careful permission handling: per the W3C Clipboard API and events specification, the read flow is gated by secure context, focus, and a user gesture, and browsers may deny it anyway.
Most developers don't need a permanent tool — they need a fast answer. An online clipboard viewer already implements the read path, the paste fallback, and the metric calculation. You avoid spending an afternoon on permission states, MDN's Clipboard.readText() reference, and edge cases like embedded iframe sandboxes. For Windows-specific debugging workflows, a companion guide on inspecting clipboard text on Windows walks through the same problem from a platform angle.
What the viewer actually measures
Clipboard Viewer reports seven distinct quantities, and the whole point is that they are not interchangeable. The table below lists each metric, what it counts, and why the result can diverge from the others during real debugging.
| Metric | What it counts | Why it diverges |
|---|---|---|
| Characters | JavaScript string length in UTF-16 code units | Emoji and supplementary-plane characters occupy two units each |
| Code points | Actual Unicode code points via Array.from | Closer to "what a human sees" but ignores encoding size |
| UTF-8 bytes | Bytes after browser TextEncoder encoding | Determines network payload size, file size, and many API limits |
| Lines | Logical lines split on LF, CRLF, or standalone CR | A pasted Windows snippet can count differently on macOS or Linux |
| Words | Unicode letters and numbers with common apostrophes, underscores, hyphens | Practical, not linguistic — a tokenizer would split differently |
| Whitespace | Spaces, tabs, carriage returns, and line feeds | Hidden formatting is the usual bug |
| JSON validity | Strict JSON.parse on trimmed text | Syntactic only — does not check field semantics or schema |
Each row is computed on demand using browser-native primitives: TextEncoder for UTF-8 size, Array.from for Unicode code points, an explicit CRLF/CR/LF splitter for lines, a Unicode-aware token regex for words, and JSON.parse for syntax classification. Nothing leaves the page.
Inspect clipboard text in four steps
- Click Read clipboard and approve the browser prompt, or paste text directly into the editor. If the browser denies the read for any reason, the editor route remains available — denial is treated as "use paste" rather than as lost data.
- Compare character, code-point, UTF-8 byte, line, word, whitespace, and JSON results side by side. Most clipboard bugs surface as a difference between two of these counts.
- Enable Show spaces, tabs, and line endings when hidden formatting may be the problem. Spaces render as centered dots, tabs as arrows, and line endings as visible symbols while the underlying editor value is unchanged.
- Clear the editor after inspection, especially when the text contains sensitive information. The clipboard can hold passwords, tokens, customer records, or private keys without your tool noticing.
When characters, code points, and UTF-8 bytes disagree
The character/code-point divergence is the most common surprise. JavaScript's string length counts UTF-16 code units, so the string "😀" reports a length of 2 but is a single Unicode code point. The supplementary-plane case matters whenever you validate user input against a database VARCHAR limit, a textarea maxlength, or a downstream API that measures characters in code points. UTF-8 byte length is independent of both: the same emoji takes 4 UTF-8 bytes, so a "4-character" emoji string can be 4 characters by code point, 8 by JavaScript length, and 16 bytes by UTF-8.
That divergence is not corruption — it is encoding reality. The tool makes it visible without taking sides. Paste a string that contains a non-ASCII letter plus a supplementary-plane emoji into the editor and the viewer reports three different totals because the string contains a multi-byte UTF-8 sequence and a 4-byte supplementary character. The exact figures come from the live counters; the point is qualitative: three metrics, three answers, none of them wrong.
The line-counting rule is similarly explicit: LF, CRLF, and standalone CR are all recognized as line endings. That matches what most editors, log analyzers, and shell tools actually do, which is why comparing clipboard text between Windows, macOS, and Linux produces consistent results once you know the rule.
JSON validity, invisible characters, and privacy
The JSON indicator performs a strict JSON.parse on the trimmed value. A green light means only that the text is syntactically valid JSON — not that its fields are safe, not that its URLs are reachable, and not that it parses as the schema you expected. The tool does not repair JSON, run code, follow links, or interpret pasted HTML. If you need structured validation with a schema, a dedicated JSON Validator or JSON Formatter handles that separately.
Invisible-character inspection is the other major use case. A copied shell command with a non-breaking space will fail in bash without any visible hint. YAML indentation built from a mix of spaces and tabs can collapse to an empty mapping. CSV rows exported from one OS and imported on another can carry stray CRs that break the row count. Showing spaces as centered dots, tabs as arrows, and line endings as visible symbols turns those silent failures into obvious ones, without modifying the editor value.
Privacy is the central design constraint. Analysis runs locally in the current tab, no clipboard text is submitted to a Lizely server, and clearing the editor removes the working value from component state. The tool reads text only — it does not expose clipboard images, rich HTML, files, or platform-specific formats. If the browser refuses to grant clipboard access because of policy or permission state, the manual paste path keeps the workflow usable. The input budget prevents an accidentally enormous paste from freezing the interface, which matters more in debug tools than in production utilities.
A clipboard viewer that does not itself become a clipboard leak is the minimum bar, and Clipboard Viewer meets it by never transmitting the text it inspects. Clipboard Viewer is an inspection tool, not a secure secret scanner, malware detector, or compliance system, so the workflow should pair it with the same caution you would apply to pasting into any other developer tool.