Batch Text File Replacer

How to use Batch Text File Replacer

Update a repeated project name, URL or multiline excerpt across a small file collection without uploading it or editing the originals. Plan every match and the complete output size first, then download all file copies together. Unchanged files, original UTF-8 BOMs and unmatched line endings stay intact, while each source and result has its own hash and exact match coordinates.

1. Choose a flat collection of local UTF-8 files, or load the original example with a BOM/CRLF file, an unchanged emoji/LF file and an empty file.
2. Enter the exact text to find and the literal replacement. Leave replacement empty for deletion; inserted text is never searched again.
3. Run the tool and review every file’s match count, unchanged/rewritten status, original/output byte sizes, SHA-256 values and source/output coordinates.
4. Download the complete ZIP. Files are under files/ with their accepted original names; rewrite-evidence.json matches the readable report. Review copies before manually using them in place of originals.

Good to know

• One selection of 1–20 actual local files, 0–1 MiB each and at most 2 MiB combined. All filename and size limits are checked before reading. The complete sequential read has a 5-second wait; late Blob reads are ignored because they cannot be forcibly cancelled. A changed read byte count refuses the whole operation.
• Strict UTF-8 only, without charset guessing or replacement characters. One original initial EF BB BF is protected from matching and retained unchanged. Later U+FEFF values are ordinary body text. CRLF, CR, LF and final-newline state are not normalized; unmatched text stays intact. Empty, no-match or identical-replacement files are original byte copies.
• Find is nonempty; replacement may be empty. Each is at most 4,096 well-formed UTF-16 units and 16,384 UTF-8 bytes. Only exact, case-sensitive, nonoverlapping occurrences in the original body are replaced. Multiline matches are allowed. There is no regex, full Unicode folding, normalization, whole-word rule, grapheme interpretation, substitution template or replacement cascade.
• At most 1,000 matches across the selection. Every match has zero-based, end-exclusive UTF-16 and UTF-8 source/output coordinates, including one retained initial BOM as one code unit or three bytes. These are not line or grapheme columns. Planned output copies total at most 8 MiB; expansion is checked for the entire collection before allocating rewritten copies.
• Flat original filenames must be NFC, nonblank and at most 200 UTF-8 bytes, without paths, reserved Windows characters/device names, controls, outer whitespace or trailing dots. Exact and ASCII case collisions refuse. Names are not rewritten, and universal Unicode filesystem case/normalization equivalence is not certified. No folders, original timestamps, permissions or executable attributes are retained.
• A same-origin module Worker loads its fixed code and existing ZIP library before ready within 10 seconds. A separate 2-second computation deadline covers planning, SHA-256, rewriting and stored ZIP creation. Completion, errors and timeouts terminate Worker ownership and clear deadlines. A secure supported Web Crypto context is needed for hash evidence.
• Complete evidence is limited to 200,000 UTF-16 units and 800,000 UTF-8 bytes; the complete stored ZIP is limited to 9 MiB. Limits are joint and may refuse combinations. Any unsupported file, unsafe name, invalid encoding, oversized expansion or computation failure leaves no partial download. No archive is imported or decompressed.
• Original files are never overwritten, renamed, deleted, uploaded or automatically stored. The ZIP contains full selected file copies, and evidence includes names, authored find/replacement strings and hashes. This is not anonymization, syntax validation or proof of authenticity. Input code, HTML and URLs are never executed, mounted or opened by the tool; review exported source before using it elsewhere.