Why is my PDF showing a different file name than the one I saved?

Because a PDF carries a title inside the file that is completely separate from the name on disk. It lives in the document information dictionary as the Title entry, and renaming the file never touches it. Whatever the original author typed, or whatever the export tool wrote automatically, is still sitting in there.

What is DisplayDocTitle and why does it matter?

DisplayDocTitle is a flag in the viewer preferences dictionary that tells a reader to show the document title rather than the file name. W3C's PDF18 technique describes the Title entry together with DisplayDocTitle set to true as what enables a descriptive title for a PDF. That is why two files with identical Title values can behave differently: one has the flag and the other does not.

Does renaming the PDF fix it?

No, and this is the step most people try first. The file name and the internal title are stored in different places, so renaming changes what your file manager shows and leaves the embedded title untouched. Any viewer configured to prefer the internal title keeps displaying the old text no matter how many times you rename it.

Why does it look right in one program and wrong in another?

Viewers differ in whether they honour the internal title at all. The W3C technique notes that a user agent may display the page title in the window title bar or as the tab name, which is permission rather than obligation. So the same file can show its file name in one reader and its embedded title in another, and neither is malfunctioning.

Is the old title a privacy problem?

It can be, and that is the part worth taking seriously. Titles left by export tools routinely contain a draft name, an internal project code, a client name or a local file path, and they travel with the document when you email or upload it. Alongside the title, PDFs also carry author, producer and creation date fields that most people never look at before sending.

How do I see what title is actually stored in my PDF?

Open the file in a metadata tool and read the Title field directly rather than guessing from what a viewer displays. Our Remove PDF Metadata page shows the existing values when you load a file, so you can confirm what is in there before deciding to clear it. The check costs a few seconds and runs entirely in your browser.

Does clearing the metadata damage the document?

No. Metadata sits in a separate structure from the page content, so clearing it leaves every page, image and piece of text exactly as it was. We drove a test file through the tool and confirmed the page content came back unchanged while the title, author and producer fields were emptied.

Are the metadata fields deleted or just emptied?

Overwritten, and not all in the same way. Title, Author, Subject, Keywords, Producer and Creator come back as empty strings, while CreationDate and ModificationDate are set to the Unix epoch, D:19700101000000Z. A date field has to hold a valid date, so epoch zero is used as the most neutral value available. Seeing a 1970 timestamp in the result is expected, not a sign that something failed.

Why Is My PDF Showing a Different File Name? Fixed

Why is my PDF showing a different file name? Because you are looking at two different names and only one of them is the file name. The other is stored inside the document, it was written when the file was created, and renaming the file on disk does not touch it.

That is the whole mechanism, and it explains the behaviour people find maddening: you rename the file, the wrong name comes back, you rename it again, it comes back again. You are editing the label on the box while the viewer reads the label inside it.

A PDF carries two names, not one

Every PDF has a document information dictionary, and one of its entries is Title. It is plain text stored in the file, entirely independent of what the file is called on disk. A document saved as quarterly-report-2026.pdf can carry a Title of “Copy of Draft v3 FINAL” and both are correct in their own terms.

Alongside it sit companions most people never see: Author, Producer, Creator, Subject, Keywords, CreationDate and ModDate. They are written automatically by whatever exported the file, and they persist through copying, emailing and uploading.

The flag that decides which one wins

Storing a Title is not by itself enough to make a viewer show it. There is a second setting, DisplayDocTitle, which lives in the viewer preferences dictionary and tells a reader to prefer the document title over the file name.

The W3C describes exactly this pairing in its PDF18 technique for WCAG: the Title entry in the document information dictionary, together with the DisplayDocTitle flag set to true, is what enables a descriptive title for a PDF (W3C, PDF18).

The same technique is careful about what happens next: a user agent may display the page title in the window title bar or as the name of the tab. That is permission, not a requirement, which is why behaviour differs between readers. Two people opening the same file in different software can honestly report different names, and neither program is broken.

Do not expect one universal answer

Because the spec says a viewer may use the title, testing in your own reader is the only way to know what yours does. Clearing the stored title removes what a viewer would prefer, with one caveat covered further down: a PDF can also carry a separate XMP metadata stream.

Where the wrong title came from

The stored title is rarely something anyone typed on purpose. The common sources are worth recognising because they tell you what is likely sitting in your file right now:

A word processor using the first heading. Export to PDF and the Title often becomes whatever line was styled as the document heading, including a working draft name.
A template that was copied. Duplicate last quarter’s file, change the contents, and the Title still names last quarter.
A scanner or export tool writing its own text. Some write a device name, a batch number or a local file path.
A previous owner of the document. Anything you were sent carries whatever the sender’s software wrote.

Step 1: see what is actually stored

Before changing anything, read the field directly rather than inferring it from what a viewer displays. Open Remove PDF Metadata and load the file. It shows the values currently stored in the document, so you can confirm the Title is the culprit rather than guessing.

This is worth doing even when you are confident, because it separates two different problems. If the stored Title is the wrong text you have been seeing, this page is your fix. If the stored Title is empty and a viewer is still showing something odd, the name is coming from somewhere else and clearing metadata will not change it.

Step 2: clear it, and what that leaves behind

Clearing is one click from the same page. We put a test file through the live tool to confirm what it does, rather than describing it from the outside, and here is exactly what happened.

The input was a one-page PDF named quarterly-report-2026.pdf carrying a Title of “Copy of Draft v3 FINAL (do not send)”, an Author of “Finance Team” and a Producer string. After running it through the tool, the downloaded file came back as quarterly-report-2026-no-metadata.pdf with the Title reading as absent and Author and Producer reading as empty. The page itself was untouched: one page, same text.

One precise detail, because it changes what you will see if you check the result yourself. The entries are overwritten rather than deleted, and they are not all overwritten the same way. Six of them – Title, Author, Subject, Keywords, Producer and Creator – come back as empty strings. Some readers report an empty title as absent rather than as an empty string, so do not be thrown if your tool says one and this page says the other; they describe the same stored value. The two date fields, CreationDate and ModificationDate, are set to D:19700101000000Z, which is the Unix epoch. That is deliberate rather than a bug: a date field has to hold a valid date, and epoch zero is the most neutral value the library will accept, so it reveals nothing about when your document was made.

So if you inspect the result and see a 1970 timestamp, nothing has gone wrong. What matters is that the original creation and modification times are gone.

For reference, these are the fields the test file carried and what they read afterwards. It is worth knowing the shape because it tells you what to look for when you check your own file:

Title — “Copy of Draft v3 FINAL (do not send)” before, absent after.
Author — “Finance Team” before, empty after.
Producer — the name of the tool that created the file before, empty after.
Page content — one page reading “Quarterly Report 2026” before, identical after.

The file name of the download also changes, which is a small convenience worth expecting rather than being surprised by: the cleaned copy arrives with -no-metadata appended to the original name, so it sits next to the original in your downloads folder instead of overwriting it. Keep whichever one you need and delete the other.

One limit matters more than the rest, and we would rather state it plainly than let you assume otherwise. A PDF can carry a second metadata store called an XMP stream, held separately from the information dictionary. Our tool clears the information dictionary, and it unlinks the XMP stream from the document catalog, but the stream itself is still written into the saved file. We put a test PDF carrying a known XMP title through the live tool and found that title still present in the output bytes.

For a wrong name in a title bar that makes no difference, because the viewer reads the information dictionary. For a document that is actually sensitive it matters a great deal. If that is your situation, run exiftool -all= yourfile.pdf on the result, or use a desktop tool that rewrites the file, and verify rather than assume. We have logged this as a defect to fix.

The reason this matters beyond a wrong label

A mismatched name is annoying. What sits beside it is the actual risk. The fields that travel with a PDF routinely carry a draft name, an internal project code, a client name, a local file path with a username in it, or the identity of the software and machine that made the file.

None of that is visible on the page, so it survives every review that consists of reading the document. It goes out with the file when you email it to a counterparty, upload it to a portal or attach it to a filing. If you were already going to clear the title to fix the name, you clear all of it in the same step.

Two related tools are worth knowing about, because metadata is only one of the places information hides. If something on the page itself needs covering, Redact PDF bakes black rectangles into the page content so the coverage holds in every viewer, rather than being an annotation someone can drag away. Be clear about its limit, which that tool states on its own page: this is visual coverage, not content-stream removal, and the underlying text may still be recoverable by copy-paste in some readers. For legal-evidence redaction, use desktop software that strips text from the stream. And if the document carries an Aadhaar number, Aadhaar Mask covers the first eight digits in line with UIDAI’s masking guidance.

Why this runs in your browser

Reading a document’s hidden fields means opening the document. Doing that on someone else’s server, for a file whose entire problem is that it carries information you did not intend to share, is a poor trade.

Every tool linked here runs inside your own browser tab. The PDF is read by JavaScript on your device, the work happens in local memory, and the cleaned file is written straight back to your downloads folder. Nothing is uploaded, so there is no server copy holding the metadata you just removed.