Neatbo.

Exact unified diff applier

Apply one text-file unified diff at its declared lines with exact context and explicit line-ending handling.

Browser-local processingInputText + unified diffOutputPatched text / JSON reportUp to 1 MiB per file · File limit: 1
  1. 1Add input
  2. 2Adjust settings
  3. 3Get your result

Tool input and files are processed in this browser without being uploaded.

Your input

Inputs are kept temporarily in this tab when switching tools. Refreshing or closing clears them; large results may need to be regenerated.

⌘ / Ctrl + Enter to run

or drag and drop it here

Files stay on this device. Your originals stay unchanged.

.txt · .md · .js · .ts · .json · .csv · .patch · .diff

Up to 1 MiB per file · File limit: 1

    0 characters · 0 bytes
    Options

    Complete the required options first. You can keep the defaults for the rest.

    Preparing the tool…

    Before you start

    Rebuild a revised text file from its original and a patch. Check context, line coordinates and EOF markers locally before downloading the complete result.

    How to use this tool

    1. Open the original file or paste LF text, then paste the single-file unified diff into the patch field.
    2. Choose literal payload or explicitly restore CRLF. Verify the original version, declared line positions and no-newline markers.
    3. Apply the patch, inspect the hunk summary and complete output, then download patched.txt with its report.

    Supported inputs and limits

    Original UTF-8 text and patch each up to 1 MiB. One source file takes precedence over pasted source. At most 50,000 source/output lines, 100,000 patch lines and 2 MiB output. Preview includes up to 200 hunks.

    Supports single-file ---/+++ unified headers, optional git diff/index preamble, exact hunk counts, text creation/deletion and “No newline at end of file” markers. Binary, rename, mode-change and multifile patches are rejected. Header names are labels only; no filesystem path is opened.

    No fuzz or offset search. Removed/context text, declared line coordinates and line endings must match exactly. Default literal payload uses the patch’s record endings. CR-only source records and NUL binary content are unsupported. Any failed hunk stops the entire run without a partial artifact.

    Browsers normalize textarea line endings to LF. To keep a CRLF source, open it as a file and explicitly select CRLF payload when pasting a CRLF patch. This option restores CRLF for all payload records; EOF markers still remove the final ending. Leave literal mode for LF or genuinely mixed endings.

    Worked example

    Example input

    one
two
    Example options
    {"params": {}, "secondary": "--- a/file.txt\n+++ b/file.txt\n@@ -1,2 +1,2 @@\n one\n-two\n+three\n"}

    Example output

    one
three

    When something does not work

    Use the exact original version, correct hunk counts/coordinates and complete context. Remove unsupported headers or split a multifile diff. For CRLF open the source file and choose CRLF payload; do not discard context to force a match.

    Frequently asked questions

    Will it find a nearby matching line?

    No. It only accepts the old coordinates specified by the diff and validates all context exactly.

    Does it edit the file I selected?

    No. The selected file is read locally. The patched version is a separate download.

    Why does the patch fail on identical-looking text?

    Its line endings, EOF newline or source version may differ. Check exact bytes and use the explicit CRLF option only when the patch payload is CRLF.

    Documentation & further reading

    Developer tools guide: formatting, comparison and JSON patches →CSV comparison, joins and pivots: check records before reporting →

    Related tools