How to Make ChatGPT Show Its Proofreading Changes Instead of Replacing Your Draft

The short answer

ChatGPT cannot show tracked changes. There is no redline mode, no margin markup and no accept-and-reject interface for arbitrary text you paste into the chat. What it can do is enumerate its edits in a table, and that is close enough to be genuinely useful — provided you ask for the table explicitly, because the default response is just the rewritten text.

The prompt below asks for three columns: the original phrase, the corrected phrase, and the reason. It also forbids the model from inventing edits, which is the failure mode you get without that rule. Below the prompt are the results of running it, including what it missed and what it flagged that was not an error.

The three ways to see changes, compared

People searching for tracked changes in ChatGPT are usually looking at three different things. They are not equivalent, and only one of them is a workflow you fully control.

The honest summary: if what you need is a reviewable list of changes, a chat table or a dedicated editor gives you that and an in-field correction tool does not. If what you need is speed on short everyday text, the in-field tool wins and the table is overhead. They solve different problems, and this article is about the first one.

The change-list prompt

Copy this. Replace the placeholder at the bottom.

Proofread the text below and report your edits as a Markdown table.

Columns, in this order:
| Original phrase | Corrected phrase | Reason |

Rules:
1. Report only genuine errors in grammar, spelling, punctuation and
   agreement. Do not report style preferences, concision suggestions,
   tone changes or vocabulary upgrades.
2. If you are tempted to suggest something that is not an error,
   leave it out. An empty table is a correct answer.
3. Quote the smallest phrase that shows the error. Do not quote
   whole sentences unless the error is the sentence structure.
4. The Reason column must name the rule, for example "subject-verb
   agreement", "comma splice", "misspelling", "wrong homophone".
   Never write "reads better" or "clearer".
5. Never change proper nouns, names, numbers, dates, units, URLs,
   filenames, code or technical terms. Do not report them as errors.
6. Never change the level of certainty or formality. Keep hedges,
   contractions and informal register exactly as written.
7. If a sentence is ambiguous and the correct fix depends on what
   the writer meant, do not choose. Add it to a section below the
   table called "Needs a human decision" and explain the two
   readings.
8. After the table, add a line: "Errors found: N" and a line
   "Sentences unchanged: M of T".
9. Do not output a corrected version of the text. The table is the
   deliverable.

Text:
<paste your text here>

Four of those rules are doing real work. Rule 2 stops the model padding the table, which it will otherwise do because an empty table looks like a failure. Rule 4 forces a nameable grammatical rule, which is the filter that separates errors from preferences — 'reads better' is not a reason and cannot survive that column. Rule 7 is the one most people omit and most need: it gives the model somewhere to put ambiguity instead of resolving it silently. Rule 9 prevents the model from also returning a rewrite you did not ask for.

The test text

This is the paragraph we ran. It contains a deliberate mix of mechanical errors, agreement errors buried in long noun phrases, one ambiguous sentence, and several things that are stylistically loose but not wrong.

Me and the infra team has been looking at the incident from last tuesday, and their is two things we still dont understand. The dashboards shows a spike in 5xx responses starting at 14:02 UTC but the deploy log dont record any release in that window, which suggest the trigger was upstream. We think the connection pool might of been exhausted when the caching layer restarted, althought we cant prove it from the logs we have. Going forward the plan is to add a alert on pool saturation and to review the timeout values, which is currently set to 30 seconds across all of the services. I will send a summary to the client on friday unless you want me to hold it.

For reference, the errors planted in that paragraph are: 'Me and the infra team has' (two errors — pronoun case and agreement), 'last tuesday' (capitalisation), 'their is' (wrong homophone), 'two things we still dont understand' (missing apostrophe), 'The dashboards shows' (agreement), 'the deploy log dont record' (agreement), 'which suggest' (agreement), 'might of' (wrong word), 'althought' (misspelling), 'cant' (missing apostrophe), 'a alert' (wrong article), 'which is currently set' (agreement with 'values'), and 'friday' (capitalisation). That is thirteen, plus one genuinely ambiguous sentence at the end.

What the table returned

Under the table the model added the ambiguity flag we asked for in rule 7, in a section titled 'Needs a human decision': the final sentence 'I will send a summary to the client on friday unless you want me to hold it' is unclear about whether 'it' refers to the summary or the sending, and about who 'you' is. That is a correct call. The sentence is grammatically fine and semantically ambiguous, and silently rewriting it would have picked an interpretation the writer may not have meant.

What it missed

This is the section that matters. A change list you cannot trust is worse than no change list, because it makes you stop reading carefully.

What it flagged that was not an error

Rules 1, 2 and 4 suppress most of this, but not all of it. These are the false positives that survived the prompt across runs.

Notice that every one of these has a plausible-sounding reason attached. That is why rule 4 forbids 'reads better' and 'clearer' — it does not stop the false positives, but it makes them easier to spot, because a preference dressed as a rule usually names a rule that does not exist.

Applying the edits without re-typing everything

The table is the deliverable, so you still have to make the changes. Here is the fastest way that does not involve rebuilding the paragraph by hand.

1. 1

   Reject rows first, before you touch the text

   Go down the Reason column and cross out anything that is a preference rather than a rule. In our test that removed four of seventeen rows. Do this before you start editing so you are not switching between judging and typing.

2. 2

   Check the ambiguous section

   Read the 'Needs a human decision' entries and make the call yourself. This is the part no tool can do.

3. 3

   Use find-and-replace in your own editor

   For a document, work through the accepted rows with Ctrl+F and replace each original phrase with its corrected version. For a short message in a browser field, do it by hand — the overhead of find-and-replace is larger than the edit.

4. 4

   Re-read the whole paragraph once

   Twelve small edits can leave a sentence rhythmically broken even when every clause is now grammatical. Read the final version end to end.

When a change table is the wrong tool

This workflow costs you a prompt, a wait, an audit and a round of manual edits. That is a good trade for a 300-word incident report going to a client. It is a bad trade for a Slack reply.

For the in-field case, be clear about what you get. One Shot Fix shows the corrected text in a popup and you click Apply. It does not highlight the changed words and it does not produce a change list, so review means reading the corrected version rather than scanning a table. If a diff view is a hard requirement for how you work, use the ChatGPT table workflow above and do not expect it from an in-field tool.

Where this breaks down

Frequently asked questions