Text File Portability Preflight
Paste or upload a plain text file and see exactly which encoding, line-ending and whitespace quirks will make it behave differently in Git, diff tools, CI systems, Windows Notepad or older Unix tools — even though it looks completely normal in your own editor.
Processed locally in your browser. Your file is never uploaded.
How to use this calculator
- Paste text, or upload a .txt/.csv/.log/plain-text file — nothing leaves your browser.
- Select "Check portability".
- Review each flagged issue: what makes it a portability problem, and which tools it actually affects.
- Use the combined safe rewrite where offered — it normalizes line endings, strips a leading BOM, trims trailing whitespace, adds a missing final newline, and fixes whitespace look-alikes all at once.
Assumptions
- The input is already a JS string decoded by the browser (via a file input's .text() method, or pasted text) — this tool analyzes that decoded text, not raw file bytes. It cannot detect the file's original byte-level encoding directly.
- Recognises eight specific portability-relevant issues: mixed CRLF/LF line endings, bare CR-only line endings, a leading byte order mark, Unicode replacement characters, trailing whitespace, a missing final newline, mixed tab/space indentation, and Unicode whitespace look-alike characters. Anything else about text encoding is out of scope.
- A Unicode replacement character (U+FFFD) is treated as proof that a decode failure already happened before this tool saw the file — the original bytes cannot be recovered from the text alone, so no rewrite is offered for that issue.
Methodology
The text is split into lines while recording each line's own original terminator (CRLF, bare LF, bare CR, or none), which is what makes mixed-line-ending detection possible without a normalizing split throwing that information away. Each of the eight rules is then a targeted, documented check against that line/character-level data. A combined rewrite is offered only for the issues that have a mechanically safe, unambiguous fix — line-ending normalization, BOM-stripping, trailing-whitespace trimming, adding a missing final newline, and whitespace look-alike substitution/removal. Replacement characters (no fix possible — the data is already gone) and mixed tab/space indentation (the correct fix depends on an intended tab-width convention this tool can't know) are flagged only, never auto-rewritten.
Worked example
A file edited on both Windows and Unix, mixing CRLF and LF line endings
Inputs: line one\r\nline two\n
Result: Git and other line-based diff tools compare lines byte-for-byte, so every line can show as changed even when only one line's content actually changed — flagged as an error, with a safe rewrite normalizing everything to LF.
A leading UTF-8 byte order mark before a shebang line
Inputs: \uFEFF#!/bin/sh\necho "Hello"
Result: A BOM before "#!/bin/sh" stops many Unix shells from recognising it as a shebang at all. Flagged as a warning; safely rewritten by stripping the leading BOM.
A non-breaking space (U+00A0) copy-pasted in place of a regular space
Inputs: const total = price + tax;
Result: Looks identical to a normal space in most editors and fonts, but exact-match parsing and comparison treat it as a different character. Flagged as a warning; safely rewritten to a regular ASCII space.
Practical guidance
- Configure your editor and Git's `core.autocrlf` (or a `.gitattributes` file) to enforce one line-ending convention per repository, rather than fixing mixed endings by hand after the fact.
- Treat a Unicode replacement character as a data-loss incident, not a formatting quirk — re-export or re-open the original source file with the correct encoding rather than trying to patch the already-corrupted text.
- Enable "render whitespace" or "show invisibles" in your editor when working with text copy-pasted from a word processor, PDF or web page — that's the most common source of non-breaking spaces and zero-width spaces.
- Prefer spaces-only or tabs-only indentation per project, enforced by a formatter, rather than relying on every contributor's editor to happen to agree.
Common mistakes
- Assuming a file "looks fine" in your editor means it has no line-ending or whitespace problems — most editors normalize CRLF/LF and hide trailing whitespace on display, which is exactly why these issues go unnoticed until Git, CI or another tool disagrees.
- Trying to manually retype text after a replacement-character corruption instead of going back to the original source file — the specific corrupted bytes are genuinely unrecoverable from the already-decoded text.
FAQs
Why are mixed line endings and bare CR both errors, but trailing whitespace only info?
Mixed or bare-CR line endings make line-based tools (Git, diff, many parsers) misread the file's actual structure — that's a functional problem, not a style preference. Trailing whitespace is invisible and harmless to read; it only becomes noisy when it passes through a formatter or linter inconsistently, which is a much smaller, informational concern.
Why doesn't this tool fix mixed tab/space indentation automatically?
Converting correctly requires knowing whether the file's intended indent unit is, say, 2 or 4 or 8 columns per tab — a convention this tool has no way to infer from the text alone. Guessing wrong would silently change the file's visual structure, so it's flagged with exact line numbers instead.
Can this tool detect what encoding my file was actually saved in?
No — by the time this tool sees the text, your browser has already decoded the file's bytes into a JavaScript string using its own encoding guess (or the encoding you told it to use). This tool can only spot a decode failure after the fact, via the Unicode replacement character it leaves behind; it can't inspect the original raw bytes.