← All posts

Does renaming a signed PDF break the signature?

The document came back signed. The signature panel is green, the signer's name and the signing time are in it, and that panel is the only reason this copy of the file is worth more than any other.

It is also called Signed_Document_FINAL(3).pdf, and your filing convention wants 2026-08-14 Acme — supply agreement.pdf. So you have the rename box open, and you have typed nothing, because nobody wants to be the person who broke the seal on the way to the filing cabinet.

Rename it. On your own machine, in Explorer, Finder or a terminal, it is safe. But the reason it is safe is also the reason a website offering to rename it for you might not be, and that distinction is the whole of this page.

Why the file name is not part of what was signed

A certificate-based signature is a promise about bytes. The signer's software hashes a stated range of the file's contents and signs that hash, so a reader can recompute it later and see whether one byte has moved. Flattening breaks a signature because it rewrites those bytes; that page has the byte-range mechanism in full.

The file name is not in that range, and it could not be, because it is not in the file at all: a rename edits an entry in your file system, never the document, so nothing inside the PDF changes — not one byte, and not the title the document reports to a reader.

So the signature verifies afterwards exactly as it did before, and it does not matter whether you rename it once or twenty times. This is also true of moving the file within the same drive, copying it, emailing it, and putting it in a zip. A signature travels with the bytes and takes no interest in what anybody has labelled them.

The rename that is not a rename

Here is the trap, and it is the reason people arrive at this question having already broken something.

A web tool cannot edit an entry in your file system. It never sees your disk — it sees an upload. So "renaming" on a website means one of two things: your own bytes handed back with a different name on the download, which is harmless, or the document opened with a PDF library, given a matching title and saved out again. Saving is not copying, and a re-saved file is a new file from byte zero. The pages look identical. The signature is dead.

The helpful-sounding option is the dangerous one. Setting the document title is a good idea on almost every other PDF you own — it is what a reader shows in its tab and what a search engine prints — and on a signed file it is the single thing you must not do.

Our Rename PDF makes it a switch you can see. Use it as the document title too is on by default, and turning it off is what you want here: your upload comes straight back under the new name, and no library opens the document. Leave it on and you get the rewrite, honestly labelled in the run notes; the file name page sets out what each setting costs you.

The same warning covers Edit PDF metadata, which has no such switch and does not need one: changing a title, an author or a keyword list means writing the document out again, every time. There is no safe mode for a signed file there. Use it on the copy you signed from, not the copy that came back.

Where a file name really does sit inside a PDF

The name of the file is not in the document, but names of other files often are, and they are inside the signed range where you cannot touch them.

Our PDF inspector will tell you what the document currently calls itself — title, author, producer, dates, whether it is encrypted — in the browser, without uploading anything. Run it before you decide whether a title is worth keeping. Be clear about its limits: it does not report signatures at all.

The one case where renaming genuinely breaks a signature

Some signed documents are not PDFs. They are containers with a PDF inside, and in a container the file name is signed.

Detached signatures. European e-signing and government portals commonly issue a pair: contract.pdf and contract.pdf.p7s. The signature is over the PDF's bytes, so renaming the PDF does not invalidate it cryptographically — but the pair is matched by name, and a portal handed agreement.pdf plus contract.pdf.p7s will reject the submission without explaining why. Rename both halves or neither.

Signed containers. An ASiC-E container (.asice, .bdoc, and the DigiDoc family) is a zip whose signature covers a manifest listing every member by name. Rename a file inside the container and the manifest no longer describes what is there, and the signature fails immediately. The container's own name, on the outside, is free to change. Italian .p7m files work the same way: the PDF is wrapped, not sitting beside the wrapper.

To check a detached pair after any shuffling, OpenSSL answers in one line and is free on every platform:

openssl smime -verify -inform DER -in contract.pdf.p7s \
  -content contract.pdf -noverify -out /dev/null

Verification successful means the signature still matches the PDF's bytes. -noverify skips the question of whether you trust the certificate, which is a separate matter from whether the file has changed.

What a rename does break: the trail, not the seal

The cryptography survives your rename. The paper trail around it may not, and that is the real cost nobody mentions.

A signing platform's certificate of completion names the document as it was at signing. An audit log records a file name next to a hash. A covering email says "please find attached Signed_Document_FINAL(3).pdf". Rename your copy and every one of those references now points at a name that exists nowhere, which is exactly the sort of gap somebody queries two years later when the document matters.

The fix is bookkeeping, not technology. Note the original name somewhere outside the file — the folder's index, the matter file, a line in the covering email — before you change it. Do not be tempted to record it in the document's title or keywords: that is a rewrite, and it costs you the signature to solve a filing problem.

Do the naming before the signing

Everything above is easier if the naming happens first, and the ordering is the same one that governs every other change to a document that is going to be signed. Signing goes last.

  1. Get the pages right, and flatten anything that needs freezing.
  2. Set the document's title and author with Edit PDF metadata.
  3. Give the file its final name, with rename or your operating system.
  4. Apply a password with Password protect PDF if the finished document needs one — encryption rewrites the file, so it cannot come after the signature either.
  5. Sign it.

A file named properly before it is signed never raises this question again. It can still be renamed afterwards; it just never has to be.

Checking it yourself, before and after

Do not take our word for any of this, or anyone else's. Two free checks settle it:

Comparing checksums before and after settles it too, for this and for any other step you are suspicious of; the file name page has the commands for each platform, along with the desktop tools worth using when it is a hundred files rather than one.

The short version: a signature covers the contents. A name is not part of the contents. Anything that breaks a signature during a rename was doing more than renaming, and should have told you.

Tools this post uses: