What the Prompt Version Diff Checker does
This checker compares two versions of a prompt the way a reviewer reads them: section by section, instruction by instruction, with template variables tracked separately. It tells you which sections were added, removed, changed or moved, which instructions are new or gone, which were reworded - and whether a rewording made a rule stricter, looser, negated or changed a number.
A character-level text diff shows that something changed; it does not tell you that "should" became "must" or that a section moved to the end, which can change model behaviour as much as new wording. Everything here is a deterministic comparison in your browser; neither version is sent to a model, and the review exports as Markdown for a pull request.
How to use it
- Paste the old version into A and the new version into B, or load the example. Name the versions if you want the report to say v3 to v4 rather than A to B.
- Press Compare versions. The counts show sections and instructions changed; the findings list reworded instructions first, with their behaviour signals.
- Check the variables panel: an added variable means every caller must now supply it, and a removed one may leave callers sending data nothing uses.
- Open each changed section to see the line diff, then copy the Markdown review into your pull request or download it with the prompt change.
Reading the results
Reworded means an instruction was removed and a new one added that shares at least 60% of its words. Signals flag the changes most likely to alter behaviour: stricter or looser modal words (may, should, must, always, never), a negation added or removed, and changed numbers.
Added and removed instructions are sentences with no close match on the other side. A rule that was rewritten substantially appears as one removal and one addition; read them together.
Sections are matched by title, so renaming a heading shows as one section removed and one added. Reordered means the shared sections appear in a different order.
Worked example: a support prompt from v1 to v2
v1 has a preamble and Rules, Tone and Output sections. v2 keeps the preamble, changes Rules, moves Output above Tone and adds an Escalation section. The checker reports 1 section added, 1 changed, 3 unchanged, and flags the reorder.
In Rules, "Keep replies under 100 words." became "Keep replies under 150 words." - reworded, with the signal numbers changed: 100 -> 150. "You should answer in English." and "You must answer in the customer's language." share only 3 of 9 distinct words, so they appear as one removal and one addition; reading them together shows both a stricter modal and a different language rule.
"Do not discuss pricing." was removed and "Discuss pricing only using the {price_list} provided." added, introducing a new variable, price_list. That is the change most likely to break production: the calling code must start supplying a price list, or the model is told to use one it never receives.
Why prompts deserve a structured diff
Prompts are code that nobody compiles. A one-word edit from "should" to "must", or deleting a "not", changes what the model does on every request, and in a long prompt it is easy to miss in a line-by-line diff surrounded by reflowed paragraphs.
Treat prompt changes like other code changes: keep versions in source control, review them with a structured diff, and run the same evaluation set on both versions before shipping. The diff tells you where to look; only an evaluation tells you whether the change helped.
Limitations: what the result does not prove
- It compares text, not behaviour. Whether a change makes answers better needs an evaluation run on both versions.
- Rewording is detected by shared words. A rule rewritten in completely different words appears as a removal plus an addition.
- Sentences are split at full stops followed by a capital letter; unusual punctuation, very long lines or text without full stops may be grouped differently than you expect.
- Behaviour signals look for English modal words and negations only.
Privacy: where your data goes
Everything you paste, type or drop is processed in this browser tab. It is not uploaded, logged, stored or sent to analytics. Session recording and tag-manager scripts are switched off on this page.
Standards and sources
- Anthropic - Prompting best practices
- OpenAI - Prompt engineering guide
- RFC 2119 - Key words for requirement levels (must, should, may)
Frequently asked questions
How is this different from a normal text diff?
A normal diff compares characters or lines. This one first splits the prompt into its sections, matches them by title, then compares instructions as sentences and variables as names, so a moved section or a reworded rule is reported as that rather than as dozens of changed lines.
What does stricter or looser mean for an instruction?
The modal word got stronger or weaker. "May" and "can" are permissive, "should" is a recommendation, and "must", "always" and "never" are absolute. Moving from should to must usually makes a model apply a rule more rigidly, including in cases where you wanted judgement.
Why are template variables listed separately?
Because a new or removed variable needs a matching code change. If version B introduces {customer_tier}, every place that renders the prompt must now supply it; otherwise the model receives an empty value or the literal placeholder.
Does moving a section change how the model behaves?
It can. Models tend to give more weight to instructions near the start and end of a long prompt, and later instructions can override earlier ones. The checker flags reordered sections so you can confirm the move was intended.
Can I use the report in a pull request?
Yes. Copy review (Markdown) produces a summary, the reworded, added and removed instructions with line numbers, and a fenced diff for every changed section, which renders cleanly in GitHub, GitLab and most review tools.
Last reviewed by the A2Z.Tools team against the sources listed above.
