How to Stop ChatGPT From Rewriting Your Text When You Only Want Grammar Fixes

Ask ChatGPT to proofread and you usually get a rewrite. This prompt narrows it back to corrections — and the test results show exactly where it still oversteps.

By Raheel Ashraf15 min read

Tested October 2026 on Chrome, Edge and Firefox (Windows 11)

Add to Chrome

Free · works in Chrome, Edge and Firefox

On this page

The short answer

Do not ask ChatGPT to 'proofread' or 'fix the grammar'. Both are open-ended instructions that the model interprets as a licence to improve the writing. Instead, give it a constrained prompt that explicitly forbids rewriting, limits it to the fewest possible changes, names the categories it must not touch, and specifies an output format with no commentary.

The prompt below is the one we use. It is followed by the results of running it against three different kinds of text, including the edits it made that we rejected.

Why ChatGPT rewrites when you asked for corrections

It is not a bug and it is not ignoring you. Three things combine.

  1. The word 'proofread' is genuinely ambiguous. In publishing it means a narrow mechanical pass. In ordinary usage it means 'make this better'. The model picks the broader reading because that is more often what people want.
  2. Chat models are tuned to be helpful, and helpfulness is rewarded during training with outputs that look more polished than the input. Returning your text almost unchanged feels like a weak response, so the model is pulled toward making visible changes.
  3. An instruction like 'fix the grammar' has no stopping condition. Once the grammar is fixed, the model has budget left and spends it on style, concision and tone, because nothing told it to stop.

The fix is to give it a stopping condition. That is what rule 2 in the prompt below does, and it is the single most important line.

The minimal-edit prompt

Copy this. Replace the placeholder at the bottom with your text.

Minimal-edit correction prompt
Correct only the grammar, spelling and punctuation in the text below.

Rules:
1. Do not rewrite, rephrase, reorder, shorten or combine any sentence
   that is already grammatically correct.
2. Change as few words as possible. If a sentence contains no error,
   reproduce it exactly as written.
3. Never change: proper nouns, personal names, numbers, dates, times,
   units, URLs, filenames, code, job titles, or technical terms.
4. Never change the level of certainty. Keep words like "might",
   "could", "may", "should", "I think", "probably" and "maybe"
   exactly where they are.
5. Never change the level of formality. Keep contractions, casual
   openings, sentence fragments and informal wording if that is how
   the original is written.
6. Do not add information, examples, greetings, sign-offs or
   conclusions that are not in the original.
7. Output the corrected text only. No preamble, no summary, no list
   of changes, no offer of further help.

Text:
<paste your text here>

Three notes on why it is built this way. Rule 2 gives the model a stopping condition, which is the thing 'fix the grammar' lacks. Rules 3 to 5 are the categories where corrections most often turn into meaning changes, and naming them explicitly works better than a general instruction to preserve tone. Rule 7 matters because a model that explains its changes is a model that has used output budget on something other than the text, and the explanation is where unwanted edits get justified rather than reported.

Test 1: a casual message

Input
hey sara, sorry for the late reply, i was in back to back meetings all day. i think we could push the launch by a week? the staging env still have that flaky test and id rather not ship on a friday. let me know what u think

Output with the minimal-edit prompt

Before

hey sara, sorry for the late reply, i was in back to back meetings all day. i think we could push the launch by a week? the staging env still have that flaky test and id rather not ship on a friday. let me know what u think

After

hey sara, sorry for the late reply, i was in back to back meetings all day. i think we could push the launch by a week? the staging env still has that flaky test and id rather not ship on a friday. let me know what u think

What changed. One justified edit: 'still have' to 'still has'. Everything else survived, including the lowercase greeting, the unhyphenated 'back to back', the bare 'i', the abbreviation 'id', the hedge in 'i think we could', and 'u'. This is what a correct result looks like.

Audit of test 1
CategoryCountDetail
Unchanged44 of 45 wordsRegister, hedging and abbreviations all preserved.
Justified edits1'have' to 'has' — subject-verb agreement with 'env'.
Unwanted edits0None on this run.

Test 2: a professional email

Input
Hi Daniel,

Thanks for sending the contract over on Tuesday. I've reviewed section 4 and 5 with our legal team and we have two concerns.

The payment terms says net 45 but we agreed net 30 during the call on 12 September. Could you confirm which one is correct? Also the liability cap in section 5.2 is set at 6 months of fees, were under the impression it would be 12.

I'm not trying to reopen the negotiation, we just need these two point clarified before I can get it signed. If its easier to jump on a call I'm free Thursday after 2pm.

Best,
Amira

The paragraph that changed

Before

The payment terms says net 45 but we agreed net 30 during the call on 12 September. Could you confirm which one is correct? Also the liability cap in section 5.2 is set at 6 months of fees, were under the impression it would be 12.

After

The payment terms say net 45 but we agreed net 30 during the call on 12 September. Could you confirm which one is correct? Also the liability cap in section 5.2 is set at 6 months of fees; we were under the impression it would be 12.

What changed. Three justified edits: 'terms says' to 'terms say', the comma splice repaired with a semicolon, and 'were' to 'we were'. Both numbers, both section references and the date are untouched, which is the entire point of the email.

Audit of test 2
CategoryCountDetail
UnchangedAll names, numbers, dates and section referencesDaniel, Amira, net 45, net 30, 12 September, section 4, section 5, section 5.2, 6 months, 12 months, Thursday after 2pm.
Justified edits5'section 4 and 5' to 'sections 4 and 5'; 'terms says' to 'terms say'; comma splice to semicolon; 'were' to 'we were'; 'these two point' to 'these two points'.
Unwanted edits2'its' to 'it's' was correct, but the model also changed 'I'm not trying to reopen the negotiation' to 'I am not trying to reopen the negotiation' and added a full stop after 'Best'. Neither was an error.

The two unwanted edits are worth dwelling on, because they are the kind you accept without noticing. Expanding 'I'm' to 'I am' in the sentence where you are defusing tension makes the email colder at precisely the moment it needs to be warm. That is not a grammar improvement. It is a tone change wearing grammar's clothes.

Test 3: a technical paragraph

Input
The retry logic in fetchUser() currently swallow errors from the upstream service, which means a 503 is treated the same as a 404. We should seperate the two: retry on 5xx with exponential backoff capped at 3 attempt, and fail fast on 4xx. The withRetry helper already support a predicate option so this should be a small change, but I haven't tested it against the staging config yet so the backoff values might need tuning.

Output with the minimal-edit prompt

Before

The retry logic in fetchUser() currently swallow errors from the upstream service, which means a 503 is treated the same as a 404. We should seperate the two: retry on 5xx with exponential backoff capped at 3 attempt, and fail fast on 4xx. The withRetry helper already support a predicate option so this should be a small change, but I haven't tested it against the staging config yet so the backoff values might need tuning.

After

The retry logic in fetchUser() currently swallows errors from the upstream service, which means a 503 is treated the same as a 404. We should separate the two: retry on 5xx with exponential backoff capped at 3 attempts, and fail fast on 4xx. The withRetry helper already supports a predicate option so this should be a small change, but I haven't tested it against the staging config yet so the backoff values might need tuning.

What changed. Four justified edits: three verb agreements and the spelling of 'separate'. The function names, the status codes, the shorthand '5xx' and '4xx', and — critically — the hedge 'might need tuning' all survived. The missing comma before 'so' was left alone, which is defensible; it is a style preference rather than an error.

Audit of test 3
CategoryCountDetail
UnchangedAll identifiers and technical shorthandfetchUser(), withRetry, 503, 404, 5xx, 4xx, 3 attempts, 'exponential backoff', 'predicate option', 'staging config'.
Justified edits4swallow/swallows, seperate/separate, attempt/attempts, support/supports.
Unwanted edits0 on this runOn an earlier run the model also inserted a comma before 'so' and changed 'fail fast' to 'fail quickly'. Both were rejected. 'Fail fast' is a term of art and 'quickly' is not the same claim.

How to audit the output in fifteen seconds

The unwanted edits in these tests were all the same shape. Once you know what to look for, checking is fast.

  1. Diff by eye on length. If the output is noticeably longer than the input, the model added something. Rule 6 forbids that, and it is the easiest check.
  2. Look for contractions that expanded. 'I'm' to 'I am', 'don't' to 'do not', 'we'll' to 'we will'. Each one raises formality by a step, and none of them is a grammar fix.
  3. Look for hedges that moved or doubled. 'could' to 'could consider', 'might' to 'may', 'I think' deleted. These change what you are committing to.
  4. Check every number, name and date against the original. Do not skim this. It is the one category where an error is expensive rather than merely annoying.
  5. Read the output aloud. If it does not sound like something you would say, put the sentence back.

Step 2 and step 3 catch most of it. In the three tests above, every unwanted edit was either an expanded contraction or a shifted hedge.

When to stop using ChatGPT for this

A chat model is a reasonable proofreader for a long document you are going to read carefully anyway. It is a poor fit for short everyday text, for four reasons.

Chat model versus a dedicated correction tool for everyday text
FactorChatGPT with a minimal-edit promptA correction extension
SetupPaste a prompt, paste your text, copy the result backClick an icon where you are already typing
ConsistencyVaries by model version, tier and phrasingSame behaviour every time
Instructions neededSeven rules to keep it from rewritingNone — correction is the only thing it does
Unwanted editsExpect one or two per pass, requiring an auditFewer, and they are the same kind each time so you learn to spot them
Context left behindYour text is pasted into a chat threadCorrected in place in the field
Best forLong drafts, documents, structural feedbackMessages, prompts, comments, form answers

The setup row is the one people underestimate. Pasting a message out of a composer, into a chat, then back again takes longer than correcting the message did. For a two-sentence reply, the round trip is the whole cost.

Where this breaks down

Where this breaks down

  • The prompt reduces rewriting but does not eliminate it. Across the three tests we recorded two unwanted edits in the email and none in the other two, and an earlier run of the technical paragraph produced two more. Expect to reject something.

    Workaround: Always diff against the original. Never paste a model's output straight into a message you are about to send.

  • Results are not stable across model versions or account tiers, and ChatGPT does not show you which model answered. A prompt that works today may over-edit next month.

    Workaround: Re-run the prompt on a text you know well after any noticeable change in output quality, and re-audit.

  • Long inputs get truncated or summarised. A chat model will happily return the first part of a 2,000-word document and stop, and the missing tail is easy to overlook when you paste it back.

    Workaround: Work in sections under a few hundred words, and check that the output ends where your input ended.

  • Rule 7 suppresses explanations, which means you get no record of what changed. That makes the audit entirely manual.

    Workaround: Use the change-list variant of the prompt when you want the model to enumerate its edits. See the companion guide on making ChatGPT show its proofreading changes.

  • The model cannot know your intent. It will fix 'we should ship on Friday' without knowing that you meant it as a question, and it will preserve a hedge you actually wanted removed.

    Workaround: Read for meaning separately from reading for grammar. They are two passes and only the first one is automatable.

Frequently asked questions

Why does ChatGPT rewrite my text when I only ask for grammar fixes?

Because 'proofread' and 'fix the grammar' are open instructions with no stopping condition, and the model is tuned to return outputs that look more polished than the input. Give it an explicit no-rewrite rule and a fewest-words-changed rule and the behaviour narrows considerably.

What is the shortest prompt that actually works?

'Correct only the grammar, spelling and punctuation. Do not rewrite any sentence that is already correct. Change as few words as possible. Output the corrected text only.' That covers the essentials, but adding the protected categories — names, numbers, certainty, formality — measurably reduces unwanted edits.

Does the minimal-edit prompt work on every kind of text?

It worked well on a casual message, a professional email and a technical paragraph. It is weakest on very long documents, where the model truncates or summarises, and on text with heavy domain jargon unless you name the terms in rule 3.

How do I spot an unwanted edit quickly?

Check output length against input length, look for contractions that expanded, look for hedging words that moved or doubled, and verify every name, number and date. In our tests every unwanted edit was an expanded contraction or a shifted hedge.

Is ChatGPT or a grammar extension better for everyday messages?

An extension, for short text. The round trip of copying a message into a chat and back takes longer than the correction itself, and a chat model needs instructions to avoid rewriting while a correction tool does not. ChatGPT is the better choice for long drafts and structural feedback.

Can I make ChatGPT show me what it changed?

Yes, by changing rule 7 to request a list of original phrase, corrected phrase and reason. That variant is slower to read but makes the audit much easier. It is covered in the companion guide on making ChatGPT show its proofreading changes.

Related guides

ChatGPTpromptingproofreadingno rewritingAI writing tools

Written by Raheel Ashraf, builds and maintains one shot fix. Tested October 2026 on Chrome, Edge and Firefox (Windows 11). Last updated 7 October 2026.

Write naturally. Send clean.

Correct prompts, emails and messages in the browser field you are already typing in. Free to install.

Add to Chrome