← All posts

Does renaming a PDF change what is inside?

21 August 2026

You renamed a PDF. Then you stopped, because the file is going to a client, a portal or an archive, and somebody down the line is going to check it — and you are no longer certain whether what you just did counts as editing the document.

Or you renamed it and nothing happened. The browser tab still says the old thing, the search result still says the old thing, and now you are wondering whether the rename took at all.

Both questions have the same answer underneath, and it is worth two minutes because it decides whether a signed document still verifies.

What renaming actually does

A file name is not stored inside the file. It lives in the directory — a list of names, each pointing at a record of where the contents are. Renaming edits that list. Nothing opens the PDF, nothing reads it, and not one byte of it is written.

So after an ordinary rename in Explorer, Finder or a terminal:

• The contents are identical. Same size, same checksum. It is the same file with a different label on the shelf.
• The title inside the document has not changed, because that lives in the file and the rename never touched the file.
• A digital signature still verifies, because the name was never part of what the certificate covers. Renaming a signed PDF has the reasoning, and the two container formats where it stops being true.
• Date modified does not move. It records when the contents last changed. On Windows the created date stays put too.

One thing does move, on macOS and Linux: the inode's status-change time, ctime. ls -l does not show it and ls -lc does. It updates because the link to the file changed, and it is why a backup or sync agent sometimes re-uploads a renamed file that is byte for byte what it already had.

The exception is moving rather than renaming. Dragging a file to another folder on the same drive is a rename — the directory entry moves, the contents do not. Dragging it to a USB stick or a network share is a copy followed by a delete: new bytes get written at the far end, and the copy gets its own created date. The contents still match. Everything around them is new.

Prove it in ten seconds

You do not have to take anyone's word for this, including ours. Take a checksum before and after:

sha256sum invoice.pdf          # macOS: shasum -a 256
certutil -hashfile invoice.pdf SHA256    # Windows

Identical digests mean identical files. This is the general answer to "did that step change anything", and it is worth keeping in your head for every tool you are about to be suspicious of.

For what is inside rather than what the bytes add up to, our PDF inspector reads the document title, the author, the producer, the created and modified dates and whether the file is encrypted, in your browser, without uploading anything. Run it before and after and you can see for yourself which fields a tool touched.

Where a rename does change the file: doing it on a website

This is the part nobody writes down, and it is the reason the question is worth asking at all.

Plenty of online "rename PDF" tools do not rename anything. They open the document with a PDF library and save it again under a new name. Saving is not copying. The library rebuilds the object structure, recompresses the streams, writes a fresh cross-reference table and often stamps a new modified date. The pages look the same and the bytes are entirely different — different size, different checksum, and anything that verified the old bytes now fails.

The victim is usually a signature. Re-saving a signed PDF invalidates it, for a job that should have been a directory edit; that case has its own page because the details matter.

Our Rename PDF makes the difference explicit rather than hiding it. There is one option, use it as the document title too:

• Turned off, the bytes you uploaded are handed straight back with a new name on the download. Nothing is re-saved. The checksum matches what you sent. The notes say so: "The document itself is untouched — only the file name changed."
• Left on (the default), the document is genuinely written out again, because setting a title means changing the file. That is the trade, and it is stated in the notes as well.

The other half of the question: why the tab did not change

If you renamed the file hoping the browser tab would follow, it will not, and now you know why — readers are not showing you the file name.

A PDF carries a title inside it, in a small dictionary of information about the document. That is what Chrome, Edge and Firefox put in the tab when the file has one, and what Google prints as the blue link text for a PDF result. It was usually written once, automatically, years ago, and it travels with the bytes wherever they go. The file name belongs to your disk and stops at your disk.

Which is how a file called 2026-annual-review.pdf introduces itself to everyone else as Microsoft Word - Draft3.doc. If you have already tried to fix that and the old string keeps coming back, the file almost certainly holds two copies of its title and your editor changed one of them.

Setting both at once is exactly what the rename tool's title option is for. Setting the title without touching the file name is Edit PDF metadata, where every box left empty means "leave that field alone".

One thing neither tool does: Acrobat has a per-document flag, DisplayDocTitle, and while it is off Acrobat shows the file name in its window bar no matter what the title says. We do not set it. The title page has the one-line fix.

Encrypted files, and the order to do things in

Renaming a password-protected PDF on disk is completely safe. The encryption is in the contents and the name is not, so the password is unchanged and nothing has to be decrypted to change the label.

Asking a tool to write a title inside one is a different matter — it has to open the document first, and ours will refuse: "That PDF is password-protected. Unlock it first, or enter its password." So for an encrypted file, name-only is the only mode available here.

If you are doing several of these things to the same document, the order that avoids re-work is: set the title, then rename, then Password protect PDF last. Encrypting produces a new file, so anything you do afterwards means unlocking it again. A signature goes after all of that, for the same reason — the signed-file page has the full sequence.

Renames that other people can see

A rename is local until it is not, and the cases differ:

• An email attachment carries its name in the message, not in the PDF. Renaming your downloaded copy changes your copy. The recipient's copy still says whatever the sender's did.
• Google Drive, Dropbox and OneDrive identify a file by an internal id, so renaming does not re-upload the contents and does not break a share link you have already sent.
• A file on a web server is the opposite: the name is the address. Rename it and the old URL is a 404, for every page that links to it and for the search result that has been indexed for months. Put a redirect in before you touch the name.

When a desktop tool is better, and it often is

Say this plainly: our rename does one file per run, with a name you type. There is no batch mode and no pattern. For a folder of scan_0043.pdf you want something local, and all of these are free:

• mv old.pdf new.pdf on macOS and Linux, ren at a Windows command prompt, or PowerShell's Rename-Item. For a whole folder, for f in *.pdf; do mv "$f" "2026-03-11 $f"; done is a rename per file and touches no contents.
• PowerRename, part of Microsoft PowerToys, does search-and-replace renaming across a selection with a live preview of the result. It is the right tool for a hundred files and it is a genuine rename.
• Finder on macOS: select the files, right-click, Rename, and it will do find-and-replace, numbering or a common prefix.
• ExifTool if what you actually want is titles rather than names — it works across whole directories. Read the warning about incremental updates on the title page before you use it on anything confidential.

What renaming will not do

It does not change a word on any page. If the old name is printed on the cover, or sitting in a header, that is page content and no naming tool reaches it.

It does not repair anything. A name-only rename hands back your exact bytes, so a damaged file comes back damaged.

Some characters cannot survive. Slashes, colons, asterisks, question marks, quotation marks, angle brackets and pipes are not legal in a Windows file name, so they are stripped and the notes report the name actually used. Names are capped at 120 characters.

It is not anonymisation. A better file name hides nothing. The author, the producer and the dates are all still in the document, and so is everything on the pages.

The short version: renaming a PDF changes the label, not the document. Any tool that changes the document while renaming it is doing something extra, and it should tell you.