A clipboard viewer alternative that runs entirely in the browser reads the text you have copied, counts it in several different ways, and renders invisible whitespace and line endings as visible symbols without installing any software. Clipboard Viewer accepts either a direct clipboard read through the browser Clipboard API or a manual paste, then immediately reports UTF-16 code units, Unicode code points, UTF-8 byte length, logical lines, word-like tokens, whitespace characters, and JSON validity for the same string of text. The same pasted value can produce different totals across those counts without any underlying corruption, so a controlled inspection surface prevents the surprises that show up the moment copied text is dropped into source code, configuration files, database fields, shell commands, or web forms. Because the analysis happens in the current browser tab, you can examine clipboard text the instant something looks wrong, without spinning up a heavyweight desktop utility or trusting a remote service with potentially sensitive content such as tokens, API keys, or customer records.
Choosing a Browser-Based Alternative to Native Clipboard Viewers
Operating systems have long shipped their own clipboard inspectors. Windows includes a small program historically called clipbrd.exe that surfaces whatever single entry currently sits in the system clipboard, and a number of third-party Windows utilities expose CF_UNICODETEXT, CF_HTML, CF_BITMAP, and other registered formats with tabs for images and rich content. macOS and Linux distributions expose the clipboard through command-line tools and lightweight viewers, and many phones show only the most recently copied snippet through a floating bar. Those built-in inspectors answer a narrower question than most debugging sessions actually need: what is on the clipboard right now, and in which formats?
A browser-based alternative answers a different, more practical question. Instead of asking which clipboard format is currently present, it asks what the underlying text really contains. It treats whitespace as visible evidence rather than invisible state, breaks a single string into the count types that matter for code and data, and provides a JSON sanity check that catches trailing commas or unbalanced braces before they reach a parser. Because the tool is a normal web page, it travels with you to any device that can open a modern browser, including Chromebooks, locked-down workstations, and tablets that would never accept a traditional clipboard utility. There is no installer, no native dependency, and no separate binary to keep updated.
Inspecting Hidden Characters and Text Statistics
The workflow is intentionally short so it fits inside a normal debugging cycle rather than becoming a side project.
- Open Clipboard Viewer, click Read clipboard, and approve the browser prompt that asks for clipboard read permission, or skip the prompt and paste text directly into the editor with Ctrl+V on Windows and Linux or Cmd+V on macOS.
- Read the immediate analysis alongside the editor: character code units, Unicode code points, UTF-8 byte length, logical lines, word-like tokens, whitespace characters, and the JSON indicator update without a separate submit step.
- Enable Show spaces, tabs, and line endings whenever hidden formatting could be the cause of the bug; spaces render as centered dots, tabs as arrows, and carriage returns and line feeds appear as explicit symbols while the underlying editor value stays unchanged.
- Compare the counts side by side or paste a corrected version into the editor to see exactly which character changed and how the totals moved.
- Clear the editor after inspection, especially when the clipboard text contained passwords, session tokens, customer records, or any other data you would not want to linger in component state.
Each step keeps the focus on the same string you copied, so the inspection reflects the real input rather than a retyped approximation that would silently drop the very characters you are trying to debug.
Where Hidden Formatting Breaks Real Workflows
Clipboard problems are rarely about the characters you can see. A YAML indentation that quietly mixes tabs and spaces will parse on your laptop and reject in CI. A CSV row pasted from Excel can carry a trailing CR that breaks a Unix pipeline. A shell command copied from a documentation page may include a non-breaking space at the end, so the terminal prints "command not found" and nobody can see why. An environment variable exported from one shell and read by another may carry an invisible zero-width joiner that survives the trip but corrupts equality checks in code. None of those issues surface if the only feedback is "string length: 12".
The same problem appears in source code itself. A string literal pasted from a chat window can include a smart quote that the compiler cannot match against a plain ASCII apostrophe. A function name copied from a web search may carry a zero-width space that the linter accepts but the interpreter rejects. A path copied from a file manager may contain a soft hyphen that breaks only when the path is logged. Turning spaces, tabs, carriage returns, and line feeds into visible symbols is what makes those failures diagnosable in seconds instead of after several rounds of guesses.
Understanding the Counts: UTF-16, Code Points, and UTF-8 Bytes
The tool reports three different length values for the same string because three different measurements are useful in three different contexts. JavaScript's built-in string length counts UTF-16 code units, which is why a string like "🚀" returns a length of 2 even though it represents a single rocket emoji. The code-point count uses Array.from internally and treats each Unicode scalar value as one item, so the same string reports a code-point count of 1. The UTF-8 byte length is computed with the browser-native TextEncoder and reports 4 bytes, which is exactly what the same character occupies when encoded for HTTP, file storage, or most network protocols.
| Count | What it measures | Useful when |
|---|---|---|
| UTF-16 code units | JavaScript string length | Comparing against str.length in code |
| Unicode code points | Distinct Unicode scalar values | Counting emoji and supplementary characters |
| UTF-8 bytes | Encoded byte length | Estimating file size, network payload, or database column width |
| Logical lines | LF, CRLF, or standalone CR splits | Comparing line counts across Windows, macOS, and Linux |
| Word-like tokens | Unicode letters, digits, apostrophes, underscores, hyphens | A practical readability and inspection aid |
All three length values can legitimately disagree for the same input, and that disagreement is information rather than corruption. The same is true for line counts: the inspector recognizes LF, CRLF, and a standalone CR as line endings, so a text file moved between operating systems reports the same logical line count as long as each line keeps a recognized terminator. Word counting is Unicode-aware but practical rather than linguistic, so it acts as an inspection aid for quick checks, not as a definitive authority on how a passage would be split in a particular natural language.
Privacy, Permissions, and Limits of an In-Browser Tool
The design constraint behind the tool is privacy. Analysis runs in the current browser tab, no clipboard text is submitted to a Lizely server, and clearing the editor removes the working value from component state. The implementation uses standard browser primitives rather than a custom backend, so the source of every count is auditable: TextEncoder for UTF-8 size, Array.from for code points, explicit CRLF/CR/LF splitting for lines, Unicode-aware token matching for words, and JSON.parse for syntax classification. The invisible-character view is a reversible display mapping that never rewrites the editor value underneath, so turning it off restores the original text byte for byte.
That said, the tool reads only text. It does not attempt to expose clipboard images, rich HTML, files, or platform-specific formats, and an empty or non-text clipboard simply produces an empty string. The input budget prevents an accidental enormous paste from freezing the interface, and the JSON indicator performs a strict JSON.parse check on trimmed text without repairing the input, running any code, following links, or interpreting pasted HTML. A green JSON indicator means only that the trimmed value is syntactically valid JSON, not that its fields are safe, correct, or safe to execute.
When Direct Clipboard Reading Is Blocked
Reading the clipboard directly is a protected browser capability, and the requirements are spelled out in the W3C Clipboard API specification and the MDN documentation for Clipboard.readText. In practice, direct reading generally requires an HTTPS page, a focused tab, a user gesture such as a button click, and an explicit permission grant. Even with all four in place, a request can still be denied because of user settings, enterprise policy, embedded-page restrictions, or an unsupported API surface in an older browser.
A denial is not treated as lost data. The tool surfaces a clear message, and the normal paste route remains available through Ctrl+V or Cmd+V into the editor, which is sometimes preferable anyway because manual paste keeps you in control of exactly which characters enter the page. The same fallback covers phones and tablets where the browser Clipboard API may not be available at all. For sensitive content such as passwords, API tokens, or personal records, manual paste combined with clearing the editor immediately afterward is the safer default, since the clipboard itself can carry anything you have copied since the last clear.