Text file inspector (encoding, line endings, hidden characters)
Check a text or CSV file for its encoding, byte order mark, line endings, mixed tabs and spaces, trailing spaces and invisible Unicode characters, and download a cleaned copy.
A clear answer. Here’s how.
Reads the bytes once and reports what an editor hides. The byte order mark is read first (UTF-8 EF BB BF, UTF-16 FF FE or FE FF, UTF-32 FF FE 00 00 or 00 00 FE FF) and is not counted as a character. Without one, the bytes are checked against the UTF-8 rules of RFC 3629 (no overlong forms, no surrogates, nothing above U+10FFFF) and the offset of the first byte that breaks them is given; if they are not UTF-8 the tool guesses UTF-16 without a mark (a zero in every other byte) or else Windows-1252/ISO-8859-1, which is only a guess because single-byte and Asian encodings cannot be told apart from the bytes alone. Line endings are counted as LF, CRLF and a lone CR, and the verdict says whether they are mixed. It then counts lines with trailing spaces or tabs, lines indented with tabs, spaces or both, the longest line in characters, NUL bytes, other control characters, non-ASCII characters and the most common of them, and lists zero-width, directional-mark, bidirectional-control and tag characters with their code point, byte offset, line and column. Bidirectional controls (U+202A to U+202E and U+2066 to U+2069) are the characters behind the Trojan Source attack, CVE-2021-42574, in which source code reads differently from how it runs. A comma, tab, semicolon or pipe is reported as the separator when it gives the same column count on at least 80% of the first 120 rows, with quoted fields respected (RFC 4180). The optional cleaned copy changes only what you choose, keeps every other byte of UTF-8 and single-byte files exactly, and converts UTF-16 and UTF-32 to UTF-8. The tool does not fix a wrong guess about the encoding and cannot read a file that is encrypted or compressed.
How this is checked
5 reference checks passed These 5 cases were run when this page was built, on 20 October 2026, and all reproduce within the stated tolerance. The same cases are part of the automated tests that run on every change to Toolmoz. Engine version 1.
See the checks and where each expected answer comes from
Case 1
- Inputs
- The tool’s default inputs
- Expected, and what Toolmoz gave
- Byte order mark expected UTF-8, Toolmoz UTF-8Valid UTF-8 expected Yes, Toolmoz YesTotal bytes expected 32, Toolmoz 32Total characters expected 25, Toolmoz 25Total lines expected 4, Toolmoz 4LF line endings expected 2, Toolmoz 2CRLF line endings expected 1, Toolmoz 1CR line endings expected 0, Toolmoz 0Line endings expected Mixed: 2 LF, 1 CRLF, Toolmoz Mixed: 2 LF, 1 CRLFLines with trailing spaces expected 1, Toolmoz 1Indentation expected Tabs, Toolmoz TabsInvisible and bidirectional characters expected 2, Toolmoz 2Bidirectional control characters expected 1, Toolmoz 1Longest line (characters) expected 6, Toolmoz 6Ends with a line break expected No, Toolmoz No
- Where the expected answer comes from
- Counted by hand from the 32 bytes: EF BB BF is the UTF-8 mark (3 bytes, not a character); line 1 is hello and a space then CR LF (8 characters with the break), line 2 a tab and world then LF (7), line 3 a, U+200B and b then LF (4), line 4 s=", U+202E, x and a closing quote with no break (6): 25 characters, 4 lines, 2 LF, 1 CRLF, 1 line with a trailing space, 1 tab-indented line, the longest line holds 6 characters, and 2 invisible characters of which U+202E is a bidirectional control
- Allowed difference
- exact
Case 2
- Inputs
- Or paste text or hex bytes 61 62 FF 63The pasted data is hex
- Expected, and what Toolmoz gave
- Valid UTF-8 expected No, Toolmoz NoFirst invalid byte offset expected 2, Toolmoz 2Encoding expected Windows-1252 or ISO-8859-1 (a guess), Toolmoz Windows-1252 or ISO-8859-1 (a guess)Total characters expected 4, Toolmoz 4Non-ASCII characters expected 1, Toolmoz 1
- Where the expected answer comes from
- RFC 3629 table 3: FF can never occur in UTF-8, so the first bad byte is at offset 2 (a, b, then FF); as one-byte text FF is the letter ÿ, the only non-ASCII character of the four
- Allowed difference
- exact
Case 3
- Inputs
- Or paste text or hex bytes 73 3D 22 61 E2 80 AE 62 22 0AThe pasted data is hex
- Expected, and what Toolmoz gave
- Bidirectional control characters expected 1, Toolmoz 1Invisible and bidirectional characters expected 1, Toolmoz 1Total characters expected 8, Toolmoz 8Valid UTF-8 expected Yes, Toolmoz YesEnds with a line break expected Yes, Toolmoz Yes
- Where the expected answer comes from
- U+202E (RIGHT-TO-LEFT OVERRIDE) written in UTF-8 is E2 80 AE: 0x202E = 0010 0000 0010 1110 splits into 1110 0010, 10 000000 and 10 101110; the line s=, a, the override, b, quote and LF is 8 characters
- Allowed difference
- exact
Case 4
- Inputs
- Or paste text or hex bytes id;name;score 1;Ann;3,5 2;Bob;4,0 The pasted data is text
- Expected, and what Toolmoz gave
- Delimiter guess expected semicolon, Toolmoz semicolonTotal lines expected 3, Toolmoz 3LF line endings expected 3, Toolmoz 3Line endings expected LF (Unix, Linux, macOS), Toolmoz LF (Unix, Linux, macOS)Byte order mark expected None, Toolmoz None
- Where the expected answer comes from
- Every row has 3 fields when split at semicolons but 1 or 2 when split at commas (the decimal commas), so semicolon is the only separator giving a constant column count; 3 lines each ending in LF
- Allowed difference
- exact
Case 5
- Inputs
- Or paste text or hex bytes FF FE 68 00 69 00 0D 00 0A 00The pasted data is hex
- Expected, and what Toolmoz gave
- Byte order mark expected UTF-16 little-endian, Toolmoz UTF-16 little-endianEncoding expected UTF-16 little-endian, Toolmoz UTF-16 little-endianTotal characters expected 4, Toolmoz 4CRLF line endings expected 1, Toolmoz 1Total lines expected 1, Toolmoz 1NUL bytes expected 4, Toolmoz 4
- Where the expected answer comes from
- FF FE marks UTF-16 little-endian; the units 0068, 0069, 000D and 000A are h, i, CR and LF, so 4 characters forming one CRLF-ended line, and each one-byte character leaves one zero byte (4 in all)
- Allowed difference
- exact
What this shows: the engine reproduces independently worked values for these cases. It does not prove every possible input is right. To test an answer you were given, see how to check a number; to see what is and is not checked across Toolmoz, see the accuracy ledger.
See a worked example
Worked example
A fixed demonstration, separate from the values you enter above.
- Or paste text or hex bytes
- EF BB BF 68 65 6C 6C 6F 20 0D 0A 09 77 6F 72 6C 64 0A 61 E2 80 8B 62 0A 73 3D 22 E2 80 AE 78 22
- The pasted data is
- Hex bytes, such as 68 65 6C 6C 6F
- Cleaned copy: line endings
- Leave as they are
- Cleaned copy: byte order mark
- Leave as it is
- Cleaned copy: trailing spaces and tabs
- Leave them
- Cleaned copy: invisible characters
- Leave them
- Cleaned copy: final line break
- Leave as it is
Example result
| Check | Result | What it means |
|---|---|---|
| Byte order mark | UTF-8 | The first 3 bytes are EF BB BF. They mark the encoding and are not part of the text, so they are not counted as characters. |
| Encoding | UTF-8 | The bytes follow the rules of UTF-8. |
| Valid UTF-8 | Yes | Every byte belongs to a well-formed UTF-8 sequence. |
| Size | 32 bytes | 25 characters (code points) and 4 lines. |
| Line endings | Mixed: 2 LF, 1 CRLF | LF: 2, CRLF: 1, CR alone: 0. The last line has no line break at its end. |