Git & Version Control
Inspect a unified patch, navigate changed files and keep old and new line numbers in view.
The patch stays in this browser. No upload, repository access or patch execution.
Limits: 1 MiB UTF-8, 20,000 lines and 200 files. Path filtering ignores case.
Input changed. Parse again before exporting.
Exports always include the entire patch or summary, regardless of filters and pagination.
Git diff viewer is useful when a review arrives as a patch attachment and you have neither the repository nor both complete source files. Read the changes already recorded in that attachment.
A patch viewer does not need to regenerate a comparison. It can retain the exact added and removed lines while showing which file each hunk belongs to.
Turn an existing patch into a review you can navigate.
Git diff viewer separates the old and new line numbers from a unified diff. Adjacent removals and additions are aligned by order; unchanged context stays visible on both sides. Missing source lines are never invented.
Find a file by its old or new path, then inspect only its hunks. The file filter changes the navigation, while whole-patch totals and exports remain complete. A narrowed view cannot silently produce a partial patch.
Use git diff --no-color, or a standard unified diff with paired file headers. Remove mail envelopes by exporting a bare diff from the source repository.
The side-by-side diff pairs adjacent removed and added lines in their original order. Switch to unified when the exact sequence of deletions and insertions matters more than column alignment.
Compare the whole-patch file, hunk and text-line totals with the selected file. Binary markers are counted separately because they contain no inspectable binary payload.
New files use /dev/null on the old side; deleted files use it on the new side. Git rename, copy and permission headers remain visible even when there is no text hunk. Paths quoted by Git are decoded for navigation.
Each @@ range declares old and new line counts. The parser checks them against context, deletions and additions, rejects truncated or overlapping ranges, and points to the input line to inspect. It does not repair the evidence.
The JSON summary includes every file path, status, mode when supplied, text additions, deletions and hunk count. A binary marker is reported separately, so zero text lines never implies identical binary content.
Bare Git patches and standard unified diff with paired --- and +++ headers are supported. Both display modes use the same parsed data. Combined diffs, email wrappers, ANSI colors and binary payloads are outside the supported format.
Yes. Rename and copy headers show the old and new paths, and mode-only changes remain visible. A binary marker is displayed as metadata only; the actual binary bytes are neither available nor validated.
No. Pasting and local file reading do not upload the patch. There is no URL import or share-link storage, and this viewer never opens a repository.
Use split view to compare the two line-number columns. Use unified view to preserve the patch’s original insertion and deletion order. Split pairing follows line order and does not claim that paired lines have matching meaning.
No. The view highlights added and removed lines, not programming-language tokens. Code and HTML inside a patch are rendered as text; viewing a patch does not execute it.
Still have a question?
Open Git diff viewer with a plain patch, inspect a changed path and export the complete original when the counts make sense.
Structural validation cannot establish repository applicability.