Hands on · Review
Read the changes side by side. Then decide them.
One compare renders as a side-by-side review in the browser — the original on the left with deletions struck through, the revised on the right with insertions underlined, moves carrying Word's real double decorations. Three views of the same comparison, a clickable list of every change, and — when the reviewer is done — a working copy or an accept-only redline. Self-hosted; nothing stored.
One compare, three ways to read it
Document, Changes, Reading.
-
Document
The full document, paired
Every block becomes a paragraph pair: original left, revised right. Alignment is structural — both cells come from the same block of the same comparison — so there is no scroll sync to drift out of step, and no guessing which paragraph lines up with which.
-
Changes
Only what moved, as cards
The changed blocks only, presented as cards in the manner of a pull-request diff. The unchanged bulk of the document collapses out of the way so a reviewer sees a short, finite worklist instead of a long document to scroll.
-
Reading
The revised document, in flow
Continuous prose rather than paired cells, for when the question is does the revised text read correctly rather than what exactly changed. Jumping to a change from the list works the same here as in the other two.
Built for working through a document, not admiring it
A worklist that remembers where you were.
The changes pane lists every change with a clickable anchor; the current one is marked and kept in view as you move. Step through with previous/next, filter by kind of change, and watch the overview ruler show where in the document the remaining work sits.
- ✔Viewed changes collapse. Marking a change viewed dims and folds it, so what is left on screen is what is left to do — reopen any of them for a second look.
- ✔Progress survives a refresh. Held in your own browser, keyed to that review — never sent to the server, which remembers nothing between requests.
- ✔Headers and footers included. Changes in running headers and footers appear in the review too, with their own toggle — not silently skipped.
- ✔Word and Excel pairs. A
.docxpair or an.xlsxpair both open in the review.
A link, not an attachment
Share the review; the repository stays the record.
A rendered review gets its own URL. Send it and a colleague opens the same comparison without re-uploading the pair or paying for the compare again. It is deliberately a cache of a computation, not a system of record — reviews are swept on the retention policy you configure, and your DMS remains the place the documents live.
Worth being precise about: the review itself is a view streamed into the page — nothing is downloaded and it makes no verification claim of its own. The proof travels with the produced redline, which is re-checkable on the Verify page whenever you like.
The end of a review is a decision
Two ways out, and the server checks before it emits.
-
Some changes questioned
The author's working copy
Decide each change, raise change requests where you disagree, and the working copy is rebuilt from the revised input: your comments at the anchors they belong to, a Requests sheet prepended, a decisions sidecar, and an integrity mark — so the author receives something actionable rather than a list of remarks in an email.
-
Everything accepted
The accept-only redline record
When every change is accepted and no request is open, the standard compare runs on the stored inputs and returns the record artifact for the family — a baked
.docxredline for Word pairs, a colored.xlsxreview copy for spreadsheets — with the summary report and verification included.
Same engine, same proof stack
The reviewing surface for a comparison that already proves itself.
One compare feeds all of it — the side-by-side review, the downloadable redline, the report, the certificate. In the UI it is a page; in a pipeline it is a REST call that returns the review or its outputs. Self-hosted, deterministic, nothing stored.