Medical scans and X-ray images: what metadata removal doesn't cover

This page is written for the person who owns the images: a patient with a portal download, a parent with a child's X-ray, someone photographing a film on a lightbox, somebody about to ask the internet what a shadow on an ultrasound means. It is general information about file layers rather than legal or medical advice, and the one part worth saying twice up front is that reducing a copy for strangers and handing your records to a clinician, an insurer or a lawyer are opposite jobs. Nothing below argues for altering a file somebody needs intact.

Four different files people call "my scan"

The single biggest source of bad advice here is that the file in front of you is usually not the file the standards are about. Work out which of these you are holding first, because the answer changes everything that follows.

A true DICOM study. The clinical format: individual .dcm objects, often many per series and several series per study, usually delivered on a disc or in a zip with an index file and sometimes a bundled viewer. Its header is not an afterthought like EXIF — it is a structured attribute set that the modality and the hospital system fill in by design, typically carrying patient name, patient identifier, birth date, sex, study and series dates and times, accession and study identifiers, the institution and department, referring and performing physician names, and device make, model and software version. A browser image tool cannot open any of this, including the one on this site.

An export or screenshot from a portal or viewer. A JPEG or PNG, and the file most readers actually have. The DICOM attribute set is gone — which is why people assume it is clean — but the viewer that produced it generally rendered the identifying header into the picture, so the name, the identifier and the study date are sitting in the corners as text. The tag layer is empty and the identity is fully legible.

A phone photo of a film, a monitor or a printed report. This is an ordinary phone photo with an ordinary phone photo's header: GPS coordinates, capture timestamp with time-zone offset, device make, model and in some cases a serial, plus whatever the gallery or editing app added. The coordinates are the clinic, the clinic implies the specialty, and the specialty implies the condition — which is a more sensitive inference than most location leaks on this site. This is the one case where the rest of the site applies directly, and the nearest guide is what metadata does a scanned document have, since phone "scan" apps behave like the camera rather than like a scanner.

A PDF report with images inside it. Not an image file at all. It has its own document properties, it can embed the original picture at full fidelity regardless of how small it looks on the page, and it is outside what an image tool can process.

Why de-identification is a procedure, not a cleaning step

It is worth knowing how the clinical world handles this, because it makes the two-layer problem explicit in a way consumer advice never does.

The DICOM standard devotes Part 15, Annex E to attribute confidentiality profiles, normatively: a Basic Application Level Confidentiality Profile, plus a set of options that either remove further information or deliberately retain information the base profile would have cleared. The existence of that options list is itself the lesson — de-identification is not one switch but a set of decisions about what a particular recipient may keep.

One of those options is the part that matters most to anyone sharing a picture. The Clean Pixel Data Option states that when it is specified alongside the basic profile, information burned into the pixel data corresponding to attributes the profile removes must also be removed, and that the attribute Burned In Annotation is then set to a value of "NO". The standard is candid about why this is a separate option rather than part of the baseline: it may be extremely burdensome to implement in practice, and it is unnecessary for the majority of modalities that do not burn in such annotation at all. It gives the contrast directly — CT images do not normally contain burned-in annotation, whereas ultrasound images routinely do. It also notes that although text detection and optical character recognition can locate burned-in text, deciding whether that text is identifying information or something else is not trivial, so the most conservative approach of removing any and all burned-in text is compliant but may sacrifice useful content such as localizer posting and manual graphic annotations.

Read that as a practical instruction rather than a standards footnote. A body that spent years formalising this concluded that the text in the picture is a distinct problem from the attributes in the header, that it is the harder of the two, and that machines differ in whether they produce it. An ultrasound still is near-certain to have a banner. A chest film from a viewer export probably has one too, added by the viewer rather than the modality.

The regulatory side points the same way. In the United States, the HIPAA privacy rule's safe-harbor method at 45 CFR 164.514(b)(2) lists the identifiers to be removed for a record to count as de-identified, and several entries on that list are things that live in pictures and image headers rather than in a database: names; all geographic subdivisions smaller than a state; all elements of dates except year for dates directly related to an individual; medical record numbers; health plan beneficiary numbers; account numbers; device identifiers and serial numbers; IP addresses; biometric identifiers; full-face photographic images and any comparable images; and a catch-all for any other unique identifying number, characteristic or code. Device serial numbers and full-face images being on the same list as names is the point: a phone photo's header and a clinical photo's content are both carrying listed identifiers. Those obligations fall on regulated entities rather than on a patient sharing their own images, and other countries frame it differently, so treat the list as a usable definition of "identifying" rather than as a rule that applies to you.

A workflow before you share a clinical image

1. Decide what the recipient actually needs. A clinician, insurer or lawyer who asked for your records needs the file as it is. A forum, a support group, a social post or a stranger offering an opinion needs the anatomy and nothing else. Almost every mistake here comes from running one process for both audiences.
2. Work on a duplicate and keep the original untouched. Copy the file out to a working folder first. Clinical images are records you may need later in their delivered state, and cropping or re-encoding the only copy you have is not recoverable.
3. Identify which of the four file types you are holding, using the section above. If it is a DICOM study or a PDF report, a browser image tool is the wrong instrument and no amount of persistence changes that.
4. For a DICOM study, ask rather than improvise. Imaging departments and clinics deal with release requests routinely, and asking whether they can provide a de-identified export, or simply a plain JPEG or PNG of the one view you care about, is usually faster and safer than converting a study yourself.
5. Read the picture before you touch the header. Zoom into all four edges and both top corners. Look for the name and identifier strip, the study date and time, the institution name, an accession number, a requisition or label photographed alongside a film, a wristband in a clinical photograph, a reflected room or monitor, a sticky note, or a laser-printed footer on a page you photographed.
6. Crop or cover, and flatten the result. Cropping is the strongest move because the pixels cease to exist — but only if the export is flattened, since a non-destructive crop in some editors retains the full original frame inside the file. If you must cover text that overlaps anatomy, use an opaque solid fill and flatten it into the image, not an annotation object or a separate layer that another application can turn off. Do not rely on blur or pixelation for a short, predictable string such as a name or a record number.
7. Then strip the header layer on the resulting JPEG or PNG. This is the step a browser tool does well, and it is deliberately last: an edit after the strip can write a fresh header, and an edit before it leaves nothing for the strip to miss.
8. Check the filename and everything travelling with it. SMITH_J_MRI_2026-03-14.jpg survives every strip ever written, and so do folder names in a zip, a report file beside the image, and a disc's index. Rename to something neutral before sending.
9. Verify from the recipient's position. Open the file you are actually about to send, at full size, and inspect it as a stranger would — then re-scan the header, and look at the embedded preview too, because a thumbnail created before your crop can still show the original frame.
10. Think about the set, not the file. One cleaned image is one data point; a date in a caption, a clinic mentioned in a previous post and a condition named in the thread re-identify it without any file metadata at all.

Step 5 is the one with the most depth elsewhere on this site: the way identifying detail gets printed onto paper and into pictures rather than into tags, and why removal tools cannot reach it, is the subject of printer and scanner marks that metadata removal can't touch.

Common mistakes and misconceptions

"I stripped the metadata, so the scan is anonymous." The most common error in this whole area, and on clinical images it is usually wrong in the most visible possible way: the name is still printed across the top of the frame. An empty header and an anonymous image are different claims.

"It's an X-ray — there's nothing identifying in the picture." Burned-in text aside, images can show implanted hardware, surgical clips, dental work, prior fracture patterns and other durable, individual features. Whether that matters depends entirely on who is looking and what they already know, which is exactly why the formal profiles treat pixel content as its own problem.

"A screenshot is cleaner than the original." A screenshot does end the original file's tag layer, and it also faithfully copies the rendered banner — the identifying part. It replaces a header problem you could have solved with a pixel problem you now have to crop.

"Blurring the name is enough." For a known-format string, a degraded rendering is weak protection, and the bigger failure is mechanical: a blur or black box applied as a layer, a markup annotation or a PDF comment is frequently removable by the next application that opens the file. Flatten it, then check the flattened export.

"The portal export is already de-identified." It is an export to you, and its job is to be complete and recognisable as your record. Expect it to identify you by design, in the picture as well as around it.

"De-identified means untraceable." It means listed identifiers have been removed to a defined standard. A study date plus a hospital plus an unusual condition can still narrow a population sharply, and the rules anticipate this: the same HIPAA section that defines the safe-harbor list separately permits a covered entity to assign a code allowing later re-identification under conditions. De-identification is a reduction in identifiability, not a guarantee of anonymity.

"My clinician said it was fine to share." They were almost certainly answering a clinical question, not reviewing the file's layers for you. The two things are unrelated.

Where this site's tool fits, and where it does not

Stated plainly, because this page is about not overestimating a cleaning step. MetadataWipe accepts image/jpeg and image/png only — DICOM, PDF, raw, HEIC and video are rejected rather than processed — and it handles one file at a time, with no batch mode and no folder handling, so a study of several hundred objects is out of scope by design. On a file it does accept, it decodes the image, draws it onto a canvas at its original pixel dimensions and exports a new file from the canvas, which for a JPEG means a fresh lossy encode at a fixed quality written into the code. The result arrives with -metadatawipe added to the name, your original is left alone, and all of it runs inside the page on your own device, with nothing sent anywhere.

Its built-in check is a heuristic rather than a full parse: for a JPEG it looks near the start of the file for an APP1 segment carrying the Exif identifier and for the literal text GPS, and for a PNG it walks the chunk types looking for eXIf, tEXt, iTXt, zTXt, tIME and iCCP. It reports presence, never values. So it can tell you a tag layer exists and give you a copy without one — and it is blind, in principle and permanently, to a patient name printed in the picture. For clinical images that limitation is the whole message: the tool handles the layer it handles, and your eyes handle the rest.

Related guides

See also:

• What metadata does a scanned document have?
• Printer and scanner marks that metadata removal can't touch