Prompt AI to Proofread Without Rewriting Your Text

If you prompt AI to proofread a piece of writing, the default outcome is a rewrite. The model returns a tidier document with your sentence rhythm flattened, your word choices replaced by more common ones, and three real typos fixed somewhere inside all of it. You cannot tell what changed, so you either accept a version that no longer sounds like you or redo the work by hand.

The cause is mundane. You asked for text and the model gave you text. Ask for a change list instead and the behaviour inverts.

Why asking AI to proofread produces a rewrite

Three things are happening at once.

A proofread and a copy edit are different jobs, and the word "proofread" does not reliably select the narrow one. Proofreading catches errors: spelling, grammar, punctuation, agreement, consistency. Copy editing improves prose. Most models treat a proofreading request as licence to do both, because the broader job looks more helpful.

Second, output format drives behaviour. Anthropic's prompting best practices has a whole section on controlling the format of responses, and its general advice is to "be specific about the desired output format and constraints". Proofreading is the clearest case of why that matters: the format is not presentation, it is what decides how much of your document is in scope. When the requested output is a document, every sentence is in scope and the model has no mechanism for leaving one alone. When the requested output is a list of changes, every item costs something to justify, and the model becomes conservative by default.

Third, models have a house style and drift toward it. This is the same pull that makes different models sound alike, and it operates on your text unless you fence it off.

The diff-first prompt that makes AI proofread, not rewrite

The pattern: forbid prose output, require a structured change list, demand a reason per item, and allow the verdict that nothing is wrong.

Proofread the text below. Do not return a rewritten version.

Return a numbered list. For each change:
- ORIGINAL: the exact text as it appears, with 3 to 5 words of context either side
- PROPOSED: your replacement
- TYPE: spelling | grammar | punctuation | agreement | consistency | factual-inconsistency
- REASON: one short sentence naming the rule or the inconsistency

Rules:
- Only flag errors. Do not flag style, tone, word choice, sentence length or rhythm.
- Do not replace a correct word with a more common synonym.
- Do not change British spellings to American or the reverse. Match whatever the text already uses most.
- Do not split or join sentences.
- If a passage contains no errors, say nothing about it.
- If the whole text contains no errors, reply exactly: NO CHANGES FOUND.

TEXT:
---
[paste here]
---

Four parts earn their place.

The exact-original requirement makes every change checkable. You can search for the string, see it in context and decide in a second. Without it you get "tightened the second paragraph", which is not reviewable.

The TYPE field does real work beyond labelling. Forcing a category makes style suggestions awkward to file, because none of the categories fits, so most of them never get written. It also lets you filter: accept everything typed spelling and punctuation, read the rest.

The explicit no-synonym and no-split rules target the two most common silent edits. Both change voice without changing meaning, which makes them hard to spot and annoying to undo.

The NO CHANGES FOUND verdict is the one people leave out, and it matters most. A model asked to produce a list will produce a list. Give it a sanctioned way to find nothing and the invented corrections mostly stop. The same mechanism makes confidence scores more honest, for the same reason: the model needs an exit that is not failure.

Keeping your voice when you do want edits

Sometimes you want the copy edit, just not a personality transplant. Two additions help.

Lock the register by example rather than adjective. "Keep the register of this sample" plus two or three sentences of your own writing beats "keep it professional but friendly", because the model has a concrete target. If you do this often, the fuller approach is in locking a house vocabulary into your prompts.

Cap the intervention. "Suggest at most five changes, ranked by how much each one improves clarity" forces triage. A model given a budget spends it on the worst sentence rather than smoothing all of them.

A worked pass

Take a sentence with one real error and one stylistic quirk:

We shipped the feature on Tuesday, their was no downtime and the team was pleased.

A plain proofread request typically returns something like "We shipped the feature on Tuesday with no downtime, and the team was pleased." The comma splice is gone, the their/there error is fixed, and the slightly breathless three-clause rhythm has been ironed out without anyone asking.

The diff-first prompt returns two items instead:

1. ORIGINAL: "Tuesday, their was no downtime" / PROPOSED: "Tuesday, there was no downtime" / TYPE: spelling / REASON: "their" is possessive; the existential construction needs "there".

2. ORIGINAL: "Tuesday, there was no downtime and the team" / PROPOSED: "Tuesday, there was no downtime, and the team" / TYPE: punctuation / REASON: comma before "and" joining two independent clauses.

Now you can take the first and skip the second, and the rhythm survives either way.

Running it twice, and why that matters

One pass is a sample, not a sweep. Error detection is not deterministic, and two runs of the same prompt over the same text will return overlapping but different lists. That is awkward if you treat the output as an answer and useful if you treat it as evidence.

The cheap version of this is to run the same prompt twice and compare. Items in both lists are high confidence. Items in one are worth a look. The expensive-but-better version is to split the job by error class, running one pass for spelling and agreement, one for punctuation, and one for consistency of names, terms and numbers across the document.

Narrow passes outperform a broad one for a structural reason. A single prompt covering six error types has to hold six sets of rules in play at once, and the rarer classes lose out to the common ones. A pass that only looks for inconsistent terminology will find the client name spelled two ways in a 3,000-word document, which a general proofread almost never flags because each instance is individually correct.

For a document that matters, a sensible order is: consistency pass first, because it may change wording you would otherwise correct twice; then grammar and agreement; then punctuation last, since punctuation decisions depend on the final sentence structure.

What this will not catch

A proofreading pass checks internal consistency, not truth. If your text says a release shipped in March and the release shipped in May, the model has no way to know unless the contradiction appears in the document itself. Facts need a separate pass against sources, and models are notably willing to invent citations if you let a proofread drift into fact-checking.

It also will not catch what is missing. A paragraph that omits the step a reader needs is error-free and useless, and no proofreading prompt surfaces that. The broader structure of asking for the right output is covered in our prompt engineering framework.

Frequently asked questions

Why does AI change my writing when I only asked for a proofread?

Because you asked for text and it returned text, and because models drift toward their own style unless explicitly told not to. Requesting a change list rather than a document removes the opportunity.

How do I stop AI swapping British spelling for American?

Tell it to match whichever convention dominates the existing text rather than naming one. Models read the instruction "use British spelling" as licence to normalise everything, including quoted material.

Can I proofread a long document in one prompt?

Split it. Accuracy on error-spotting falls off in the middle of long inputs, and a change list that cites exact spans gets harder to verify the longer the document is. Section by section also makes the diff reviewable.

Should I use a grammar checker instead?

For mechanical errors a rule-based checker is faster and more consistent. The model earns its place on consistency problems across a document, such as a term spelled two ways or a name that changes halfway through.

How do I know the model has not missed errors?

You do not, from one pass. Run the same text twice and compare the lists, or run it once asking only for spelling and once only for punctuation. Narrow passes miss less than one broad one.