PDF Metadata Editor — Edit or Remove PDF Properties

The information your PDF carries that you never see

Open a PDF and you see pages. Stored alongside those pages, invisible unless you go looking, is a set of document properties: a title, an author, a subject line, a list of keywords, and two “software” fields — the creator (the app the document was originally written in) and the producer (the library or app that generated the actual PDF). These are what your operating system shows in a file’s properties panel, what a PDF reader puts in its document-info dialog, and what many cataloguing systems index on.

Most of the time this metadata is set automatically and quietly, which is exactly why it is worth controlling. A PDF exported from a word processor often carries your login name as the author, the name of the template you started from as the title, and the exact software and version as the creator and producer. A file you meant to share anonymously can announce who made it, on what, and when. This tool exists to let you see all of that and decide what stays — read what is currently there, change what should change, and remove what should not be there at all.

The first thing it does when you upload a file is read the existing values and show them to you, so editing starts from the truth of what the document actually contains rather than a blank form. Nothing is written until you choose to save.

Editing, and what “leave it blank” really means

Changing a value is the obvious case: type a new title, a new author, and save. The less obvious — and more useful — behaviour is removal. If you clear a field completely and save, that property is not set to an empty string; it is deleted from the document outright, so a reader inspecting the file finds nothing there rather than a blank. That distinction matters when the goal is privacy: an empty-but-present author field still signals that the field existed and was cleared, whereas a genuinely absent one is simply gone.

Keywords are handled a little specially. You type them comma-separated, and the tool splits them into the list structure the PDF format expects, trimming spaces around each one, so “invoice, 2024, final” becomes three distinct keywords rather than one long string. Leaving the keywords box empty removes the keyword list entirely.

There is also a small choice about the modification date. By default the tool stamps the save time as the document’s new modified date, which is honest — the file genuinely was just changed. If you would rather not advertise when the edit happened, untick that option and the modified date is left out. Either way, only metadata moves; not a pixel of the visible pages is touched.

The second copy: why XMP has to go too

Here is the part that trips up most metadata editors, and the reason this one does something extra. A PDF can store the same metadata in two places at once. The original mechanism is the small document-information dictionary — the title/author/etc. fields described above. Layered on top, many modern applications also write an XMP packet: a block of XML, embedded in the document, holding its own copy of the title, author, and more, in a richer format.

The problem is that the two copies can disagree. If a tool edits only the old dictionary and leaves the XMP packet alone, a viewer that prefers XMP — and several do — will keep showing the oldtitle and author you thought you had changed. You would have edited the metadata and yet the stale values would still surface. To avoid that trap, this tool removes the XMP stream when it saves, so the fields you set in the form are the single source of truth left in the file. It also clears the document’s persistent identifier, which otherwise lets the edited file be tied back to the original. When the source file had no XMP stream to begin with, nothing is removed and the tool says so rather than claiming a cleanup that did not happen.

An honest word on metadata and search engines

It is often claimed that setting a rich title and a long keyword list will make a PDF rank better in search engines. That deserves a realistic answer rather than a sales pitch. Search engines do read a PDF’s title and can use it — often the metadata title is what appears as the clickable heading in results, so a clear, accurate title is genuinely worth setting. Beyond that, the honest picture is more modest: the keywords field in particular has been ignored for ranking by major search engines for many years, in PDFs just as on web pages, and stuffing it will not move anything.

So set a good title because it is the label people will see and click, and set an accurate author and subject because they make your files tidy and findable in document systems. But treat metadata as document hygiene, not a growth hack. What actually determines whether a PDF is found is the readable text on its pages and the pages that link to it — the same things that matter for any document. Clean metadata supports that; it does not substitute for it.

What each field actually means

The six fields are not interchangeable, and knowing what each is for makes it obvious what to put where. The titleis the document’s human name — the label a reader or a search result shows, and the one field worth getting right on anything you publish. The author is who wrote it, which on an auto-generated PDF is frequently a login name you did not intend to share. The subject is a short description of what the document is about, and keywords are the comma-separated tags a document system can filter on.

The last two cause the most confusion. Creator records the application the content was authored in — a word processor or design app — while producer records what actually wrote the PDF, which is often a separate export library or print driver. Together they are a software fingerprint: they can reveal the exact tools and versions behind a file. If you are cleaning a document for release, those are usually the two fields to blank, and because blanking removes them entirely, the fingerprint genuinely disappears rather than being replaced by another. If instead you want everything gone in one move rather than field by field, the PDF metadata remover is the blunter instrument for that job.

Where the work happens

Everything runs in your browser. The PDF is read into memory, its metadata is rewritten in place, and the updated file is offered straight back as a download — no byte is sent to a ToolMintX server. That locality is not incidental to a metadata tool; it is the whole point. The information you are here to control — your name, your organisation, the software you use, the dates you worked — is precisely the kind of personal detail you would not want to hand to a third-party server just to strip it out. Doing the work locally means the cleanup never creates the exposure it was meant to prevent.

The tool reads and writes the PDF structure directly rather than re-rendering the pages, so the document that comes out is the same document that went in with only its properties changed. File size barely moves, and because nothing is rasterised, any selectable text stays selectable.

Related tools

If your aim is purely to strip identifying information rather than rewrite it, the PDF metadata remover clears everything in one step. When a file is locked and you cannot read its properties, remove the password first with Unlock PDF. And if you are preparing several files for release, the Merge PDF tool combines them — worth noting that a freshly merged document starts with clean, blank properties you can then set here.