We have a journal paper that got correction requests and need to be resubmitted. The changes need to be highlighted in the manuscript. How do you mark the changes? Is changing the text color enough? What if the reviewer/editor does not have a colored printer? or has color blindness?

I tried underlined text but the manuscript looked ugly and I am afraid this journal has early version that goes live after acceptance as is. Any suggestions from experience?


Thanks for all the responses. Just for clarity: I assumed that the changes need to be highlighted in the manuscript. The editor did not specify.

  • 1
    They are lots of changes. They may or may not have tools to show differences.
    – randomname
    Commented Dec 14, 2021 at 15:07
  • 7
    Perhaps ask the editor, if you think you will get a quick response. You could also return two versions of the corrected manuscript, one with changes in colour and one without. Commented Dec 14, 2021 at 15:21
  • 2
    Ask the editor how to mark up the resubmission. Commented Dec 14, 2021 at 15:21
  • 2
    Related older question specifically for LaTeX: academia.stackexchange.com/q/42519 At the time it was closed as off-topic, being too specific, I now closed it as a duplicate of this one which is more general and with more answers. Commented Dec 15, 2021 at 10:06
  • 2
    Does this answer your question? What changes should be notated in a journal resubmission? Commented Dec 16, 2021 at 3:59

8 Answers 8


TL;DR Explain the changes in a different document

Send the new article without any marks and a separate document where you detail how you have included the changes suggested or why you have decided not to include them. For instance:

  • Reviewer suggests including topic X, we have done so in Section 6.4
  • Reviewer suggests including topic Y. However, we disagree because of Z.

I agree with @Buffy on the need of having a publishable paper without modifications. I don't find it necessary either to have the changes marked letter by letter.

However, I believe it is convenient to mention in which part of the paper the changes have been made. If the reviewers are the same, they will find the resubmission easier to follow. If they are different, they will still find a publishable paper to read.

  • 3
    This works in many cases, but some editorial workflows do want to see the changes directly indicated in the text.
    – RLH
    Commented Dec 15, 2021 at 1:29
  • A similar approach would be to send 1. a publication-ready version, 2. the same version with line numbers printed, 3. the older version with the line numbers printed, 4. a document explaining the changes by referring to the line numbers, e.g. line 20-30 in V2: clarified the blabla on lines 30-40 in V1. If the editor really cares, they'll read it.
    – PatrickT
    Commented Dec 15, 2021 at 3:53
  • 6
    This seems like a "frame challenge" answer to me: OP has already decided that the changes "need to be highlighted"; they want to know what's the best way to format them. Commented Dec 15, 2021 at 10:27
  • 3
    I recently received an update that had the new paper, and a marked up version with color-coded highlights showing changes made for each reviewer’s comments, as well as a separate response to reviewers (with the same color-code). It made it really easy to see what the authors had done.
    – Peter K.
    Commented Dec 15, 2021 at 11:34
  • 4
    In my field a version with marked changes is always expected, and as a peer reviewer I really appreciate it. So I consider this answer wrong. Commented Dec 16, 2021 at 3:56

If you are writing in Latex, I recommend Latexdiff; its default seems pretty good:

red strikethroughed removed text and blue wavy underlined added text

(Image shamelessly stolen from Track changes with latexdiff).

Sometimes it chokes on some equations and complicated nested environments, but in general it's a great tool that does not require you to track changes by hand.

So, what I am suggesting including in a revision:

  1. a clean, "publishable" version of the revised document;

  2. the output of latexdiff (between the previous and current revision), to display changes;

  3. a separate "response to reviewers" document that addresses the major points raised by the referees (there's no point in describing minor changes such as "yes, we have corrected typos 1, 2, 3, 4, 5").

  • 10
    @Buffy No, the reviewer often doesn't get the Latex sources (and anyway doesn't want to spend time learning how to compile them). It's been very useful for me as an author, also for exchanging revisions with coauthors. Commented Dec 14, 2021 at 19:03
  • 6
    @randomname I generally include both a clean copy and a latexdiff copy (along with a response-to-reviewers list of changes) to make it readable while satisfying any requirement for a directly-marked document
    – RLH
    Commented Dec 15, 2021 at 1:28
  • 1
    A slightly simpler LaTeX package is changes
    – Chris H
    Commented Dec 15, 2021 at 9:43
  • 2
    @ChrisH With Overleaf, there is nothing automated as far as I know, so I think you'd have to (1) download manually a copy of the old .tex file before the first submission; (2) download manually a copy of the whole project before resubmission (3) run latexdiff locally on your computer. But if that level of effort is fine for you it should work without further troubles. Commented Dec 15, 2021 at 10:25
  • 1
    This is the correct answer! I would point out, though, that latexdiff has some bugs and complex documents often require manual correction before they will compile. Commented Dec 16, 2021 at 3:49

There is more than one way to do this. Often the journal editor states exactly what you should do. If not, you can always ask the editor.

The most common and most accurate method is to use the change tracking function of MS Word (under the Review tab). That way you have an exact record of everything you deleted and inserted. The big disadvantage of this is that if you delete a large section, it gets moved to the right margin and is pretty messy. An alternative is to track only your insertions, not deletions.

Some journals ask you to highlight your changes. I don't think you have to worry about color printers as the reviewers will most likely read your revised paper on the screen, not hard copy. Color blind reviewers might see your changes in gray, which is OK too.

The final important step is to submit a separate document that describes your changes persuasively. Set the document up like this:

Reviewer 1

Comment: Please clarify your argument about xx on p. 3.

Reply: I have reframed the argument as follows: "xxx"

Do this for every comment from every reviewer to show that you've done everything they asked you to do. If you disagree with a comment, explain why (diplomatically). Including this document also helps the journal editor detect unfair and incorrect criticism from reviewers, which happens a lot, including when the reviewers don't really read the paper.


If you are using Microsoft Word, then you can use the compare documents feature. Simply use the original submission and the updated submission in the compare documents dialog. Put label changes with "Author" to ensure anonymity (i.e., blind review). This will generate a track changes version of the document showing the changes made between the original and revised documents.

You can then upload this track change version as part of your submission (perhaps in addition to the final version without track changes) to highlight the changes you have made.

compare documents in word dialog box


One option that clearly indicates the changed parts, is colorblind-safe, and doesn't look ugly would be to highlight the changed portions with vertical black change bars along the outside edge of the page.

Example of this type of change-highlighting in the wild:

enter image description here


Other answers have addressed the workflow and submission aspects, but regarding the actual marking up, underlining is a very useful way of showing changes

This is precisely because it's too ugly to make the final version and not routinely used for emphasis (bold and italic may appear in the final document). It also prints well whatever your printer. I've used it quite a bit in internal reviewing, where the reviewer, e.g. co-author, may be working on screen or paper depending on whether they're in the office or travelling when they get time to have a look (even in one case on a Kindle with B&W e-ink display).

It also pairs well with strikethrough for removed text.

LaTeX packages soul and ulem (with the [normalem] option) will allow you to do this if you're using LaTeX and don't want to use a more specific change-tracking package.


I'm assuming the editor hasn't actually required you for a marked up document. In that case, follow their instructions.

Otherwise, I would just write the new version, making the changes you feel warranted. Don't bother to mark it up. When you resubmit it, send the editor a separate communication that says something like "We addressed all of the reviewer comments except...", and detail the ones you left undone along with a bit of reasoning.

The new reviewers might or might not be the same as the old ones. What they want to see, in either case, is a good, publishable, paper, not obeisance on conformity to their earlier comments. The editor can pass this document along with the paper.

If you start to mark it up with many changes you then get faced with indexing the changes to the reviewer comments. Messy, hard to read, and, moreover, it can force the reviewer into a mind-set that isn't optimal for a good paper. Comparing the old to the new isn't the point.

  • 2
    This answer contradicts the question. In my field, it's always required that the changes be marked. And it's always a good idea. Indexing changes is easy if you use line numbers. Commented Dec 16, 2021 at 3:51
  • @AnonymousPhysicist, given my first paragraph you are incorrect to make such assumptions. What happens in your field isn't universal. And, "indexing" changes isn't easy if the changes necessitate a rewrite. Fine for trivial stuff. But the world isn't as simple as you'd like. Write a better paper. Address the reviewers concerns. A markup can be a total mess.
    – Buffy
    Commented Dec 18, 2021 at 19:57
  • I'm not incorrect that this answer contradicts the question. Commented Dec 18, 2021 at 21:05
  • @AnonymousPhysicist, see the update to the question as well as the accepted answer. If you think I haven't answered, then flag it. But I find the attempt in your (frequent) comments to influence others to be unfriendly.
    – Buffy
    Commented Dec 18, 2021 at 21:13

Aside from a separate document, where you can much better and in a more focused manner reply to the requests of the reviewers, I tend to prepare a full diff, even if only for myself.

latexdiff was already mentioned, but if you use some kind of a version control for you paper (you rather should if you use it anyway for your code), there is another option. Here, I use git.

git diff --word-diff --color <old-state> HEAD file1 file2 file3

will give you a difference output, colored, on a terminal. Let's improve that with ansi2html and few tweaks:

  • use a script to convert terminal colors to HTML
  • adjust it a bit with sed
  • use a make rule to generate it automatically, e.g. when building a PDF:

Here is the complete rule for your Makefile (if you have one).

diff.html : content.md content.tex full.bib Makefile
    git diff --word-diff --color submission1 HEAD content.md full.bib | sh ~/bin/ansi2html.sh | sed -e 's|<style type="text/css">|<style type="text/css"> pre { white-space: pre-wrap; } |g' > diff.html

Here is how it looks like in the final diff.html:

an example of the diff.html

There are many other fancy things, like letting a CI build your paper on each commit to a remote repo, but that's a story for another time.

  • 1
    The vast majority of reviewers don't understand diff, and therefore would prefer latexdiff to this approach. Commented Dec 16, 2021 at 3:53

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .