String Inspector
Break down text by byte length, character count, encoding quirks, and line ending style.
How this tool works
Paste your text
Any text - plain, multilingual, or containing emoji and control characters.
See byte, character, and code unit counts
Three distinct measurements that only diverge once non-ASCII content is involved.
Check encoding-relevant flags
Non-ASCII, emoji, control characters, BOM, and trailing whitespace are each flagged clearly.
Read the detected line ending style
LF, CRLF, CR, or mixed - identified automatically from the actual characters present.
Quick facts
- Category
- Text Tools
- Best for
- Debugging why a string fails a byte-length validation or has unexpected line endings
About this tool
Paste any text and see a detailed breakdown built for debugging encoding and whitespace problems, not for the word/sentence/reading-time stats word-counter already covers: UTF-8 byte length versus grapheme (visible character) count versus raw UTF-16 code unit length - three numbers that are identical for plain ASCII but diverge the moment emoji, accented letters, or other multi-byte characters are involved, which is exactly the kind of mismatch that causes "off by a few characters" bugs in string-length-limited fields. It also flags whether the text contains non-ASCII characters, emoji, or control characters, checks for a leading byte order mark, flags trailing whitespace on any line, and detects which line ending convention is in use - LF, CRLF, CR, or a mix of more than one, which is a common source of git diff noise and cross-platform file corruption. Useful for tracking down why a string is failing a byte-length validation, confirming a file's line endings before a diff, or checking whether pasted text secretly contains a BOM or invisible control character. Runs entirely client-side.
Why use this tool
Distinct from word-counter
Focused on encoding and byte-level detail - byte length, code units, control characters - not word/sentence stats.
Three-way length comparison
Byte length, grapheme count, and UTF-16 code units shown together, revealing exactly where they diverge.
Line ending detection
Catches CRLF/LF mismatches before they show up as noisy git diffs or cross-platform file issues.
Flags hidden characters
Surfaces a leading BOM, trailing whitespace, or control characters that are easy to miss by eye.
Frequently asked questions
For plain ASCII text they're identical, but UTF-8 encodes any character outside the ASCII range as 2-4 bytes rather than 1, while JavaScript's string .length counts UTF-16 code units, which is 1 for most characters but 2 for characters outside the Basic Multilingual Plane (many emoji). A single "☕" emoji, for example, is 3 bytes in UTF-8 but a single UTF-16 code unit - this is exactly the kind of mismatch that breaks a byte-length database column limit or a naive character-count validation.
Characters with a Unicode code point from 0 to 31 or exactly 127 (DEL), excluding tab, line feed, and carriage return since those are expected in normal multi-line text. These are typically invisible or non-printing characters that sometimes end up in pasted text from a terminal or a poorly sanitized source, and can cause subtle bugs in code that assumes text is "clean."
Windows traditionally uses CRLF (\r\n) for line breaks while Unix-based systems (Linux, macOS) use LF (\n) alone - a file with mixed line endings, or the wrong style for a given tool, can produce confusing full-file diffs in git, break certain parsers, or display incorrectly in some text editors. Detecting a mixed or unexpected line ending style upfront helps catch this before it causes a problem downstream.
Explore more free tools
Formatters, converters, validators, and generators - all free and running entirely in your browser.
Browse more tools