rsid: the Word fingerprint that links your documents together (and how to remove it)

Last updated: 30 September 2026

Short answer: a .docx file can record an identifier for each editing session in its history, and stamp paragraphs and runs of text with the session that last touched them. Two files with the same first identifier started life as the same document. They contain no names and no text, but they can show that a "new" document was made from an old one, and roughly how many times it was saved. Word's Document Inspector does not list them.

What an rsid is

ECMA-376, the published specification of the .docx format, calls them revision save IDs and defines them in the document settings (§17.15.1.70 to §17.15.1.72). The rules it gives are short:

An editing session is a span of time that begins and ends with an event that produces an editable file, such as a save or sending by email.
Every session gets a revision save ID larger than all earlier ones in the file. The IDs "should be randomly generated based on the current time".
Changes to content in a session are stamped with that session's ID through rsid* attributes.
The settings keep a list of the IDs (<w:rsids>, §17.15.1.72) and the ID of the first session (<w:rsidRoot>, §17.15.1.71).

The stamps sit on the text itself. A paragraph (§17.3.1.22) can carry w:rsidR, w:rsidRPr, w:rsidP and w:rsidDel; a run of text (§17.3.2.25) has similar attributes that, in the specification's words, "track the editing session when the run was added" or when its formatting was last changed. The specification adds that all rsid* attributes with the same value "shall indicate that those regions were modified during the same editing session".

What they can link

The specification's own example is the clearest. Two documents both have rsidRoot 00464813 and share their first three session IDs. The specification concludes that "these documents, although they are now separate, originated from the same document", and that after they were separated "the first was saved once afterwards; and the second, twice". It also notes that the root ID "must be identical between any number of copies of the same document".

In practice, that means:

Copies are recognisable. A letter sent to two recipients from the same starting document can be shown to share an origin, and so can a "fresh draft" that was actually built on another client's or another matter's file.
History has a shape. The number of IDs in the list gives the number of sessions. The specification's example with four IDs describes a document "edited over four distinct editing sessions (i.e. it was saved three times)".
Late additions stand out. A paragraph stamped with a session ID that appears nowhere else was written, or reformatted, in a session of its own.

What they do not show, by themselves: who edited, what the earlier text was, or dates you can read off. The IDs are hex numbers. The specification says they should be generated from the current time, not that the time can be recovered from them, and we make no claim that it can.

They are also not always there. The specification says applications "can use this information as desired" and that a producer "can choose" how to write them, so a file saved by other software may have none, or different ones.

Why Office does not remove them for you

Microsoft's Document Inspector list for Word — comments, revisions, versions and annotations; document properties; headers, footers and watermarks; hidden text; custom XML; invisible content — does not include revision save IDs (Microsoft's list).

Word does have a document-specific privacy option called "Store random numbers to improve Combine accuracy", under File › Options › Trust Center › Trust Center Settings › Privacy Options. Microsoft's co-authoring troubleshooting page says it needs to be selected for co-authoring to work. That page does not say what the numbers are, and we have not found a Microsoft page that ties the option to the rsid values described in ECMA-376, so we do not suggest switching it off as a way to remove them — you may simply break co-authoring.

The name does suggest why the IDs exist: comparing and combining versions of a document. That is a reason to keep them in your working copy and remove them only from the copy you send.

Other editing ids

Some files also carry identifiers that are not defined in ECMA-376 Part 1 but come from Microsoft's extensions to the format — paragraph ids in Word files are the common example. We have not read a primary source on their rules, so we will not describe what they reveal. ScrubDrop treats them as the same kind of trace: it lists them, and removes them with the rsid category.

Removing them with ScrubDrop

ScrubDrop reads the .docx in your browser; it is not uploaded. It lists what it finds for free, including the number of rsid values and paragraph ids alongside comments, tracked changes and document properties. Removing rsids and paragraph ids is one of the structural categories in ScrubDrop Pro; the free version removes properties, comments and tracked changes.

When removing, ScrubDrop rebuilds the document from what it knows is needed, drops the rsid* attributes from the text and the ID list from the settings, then opens the result again with separate parsers to confirm none remain. A file that fails that re-check is not offered for download. The visible text and formatting are not changed by this step.

The limits are the usual ones. It does not judge what the visible text says, and the re-check is a strong signal, not a promise. Open the cleaned document in Word and read it before you send it.

Is this worth doing?

For most internal documents, no. For documents that go to an opponent, a regulator or the public, and where their ancestry matters — a template reused across clients, a settlement letter adapted from another case, a report built on a predecessor — it is a cheap step. It is also the kind of trace people do not think to look for, which is why it belongs in an audit rather than in anyone's memory.

How to check this yourself

Make a copy of the .docx and rename it to .zip. ECMA-376 defines the format as a ZIP archive.
Unzip it and open word/settings.xml in a text editor. Look for <w:rsids> and <w:rsidRoot>.
Open word/document.xml and search for w:rsidR=.
To see whether two files share an origin, compare their rsidRoot values and the first few IDs in each list.

Questions

Does Word's Document Inspector list revision save IDs (rsids)?

No. Microsoft's Document Inspector list for Word does not include revision save IDs (Microsoft's list).

What can rsids reveal about a .docx file?

Two files with the same first identifier started life as the same document, so rsids can show that a "new" document was made from an old one, and roughly how many times it was saved. They contain no names and no text.

Should I switch off "Store random numbers to improve Combine accuracy" to remove rsids?

The article does not suggest it. Microsoft's co-authoring troubleshooting page says the option needs to be selected for co-authoring to work, and the article found no Microsoft page that ties it to the rsid values, so switching it off may simply break co-authoring.

See whether a Word file carries revision save IDs before it goes out, in your browser. Free: one file at a time; every kind of hidden data is listed, and properties, comments and tracked changes are removed. Removing the IDs is part of ScrubDrop Pro. Check a file.