TXT Metadata Viewer – Analyze Text File Encoding, Line Endings, and Size

What this TXT metadata viewer tells you

A plain text file has no metadata block the way a photo or PDF does. Everything worth knowing about it — which encoding it uses, how its lines end, whether it hides invisible characters — has to be read from the bytes themselves. This tool does that in your browser and lays it out in one report: encoding and byte order mark, size, line and word counts, line ending style, the longest lines, every hidden or control character with the line it first appears on, SHA-256 and SHA-1 checksums, and a byte-by-byte frequency chart.

It's most useful when a file behaves oddly somewhere else: a script that chokes on the first line, a CSV that imports with garbled accents, a Git diff that marks every line as changed, or a config file that "looks right" but won't parse.

How to check a text file's encoding and line endings

1. Drop the file onto the box above, or click it to pick a file. Nothing is uploaded.
2. Read the notes at the top of the results. They flag the problems that usually matter: a byte order mark, mixed line endings, a missing final newline, invalid UTF-8, or characters that hide text.
3. If accented letters or symbols look wrong, change the Encoding menu. The report re-runs instantly with the new decoding.
4. Download the report as .txt or JSON if you need to attach it to a ticket or compare files later.

Reading the results

Encoding

How the file's bytes map to characters. The tool checks for a byte order mark first, then tests whether the bytes are valid UTF-8. A file that only uses basic English characters is reported as ASCII, which is also valid UTF-8.

Byte order mark (BOM)

A few invisible bytes at the very start of some files (EF BB BF for UTF-8). Windows tools often add one. It's harmless in most editors but can break shell scripts, JSON parsers, and CSV header matching.

Line endings

Which characters end each line: LF, CRLF, or CR. A file that uses more than one style is reported as mixed.

Characters

Counted as Unicode characters, so an emoji or accented letter counts once, and line break characters are included. Size in bytes can be much larger than the character count for non-English text.

Entropy

A measure from 0 to 8 bits per byte of how varied the bytes are. Ordinary prose usually lands between 4 and 5. Values close to 8 mean the content is compressed, encrypted, or binary rather than readable text.

Checksums

SHA-256 and SHA-1 fingerprints of the exact bytes. Two files with the same hash are identical; converting line endings or re-saving with a different encoding changes the hash even if the text looks the same.

LF vs CRLF vs CR line endings

Most modern editors handle all three, so the problems show up in tools instead: Bash scripts fail with $'\r': command not found when they have CRLF endings, and Git shows whole-file diffs when a teammate's editor switches styles. Pick one style per project and convert stragglers.

How encoding detection works, and where it guesses

Text files don't record their encoding, so every tool has to infer it. A byte order mark settles the question for UTF-8, UTF-16, and UTF-32. Without one, this viewer decodes the file as strict UTF-8; if every byte sequence is valid, the file is almost certainly UTF-8, because random legacy text rarely passes that test by accident.

When a file isn't valid UTF-8, the viewer checks for the regular pattern of zero bytes that UTF-16 text produces, and otherwise falls back to Windows-1252, the most common legacy encoding for Western European text. That last step is a best guess. If you know a file came from a Russian, Japanese, or Chinese system, choose the matching encoding from the menu and check that the preview reads correctly.

Frequently asked questions