How to what hidden metadata in svg files reveals about your workflow
- Step 1See what your own SVG is leaking — Open a published SVG in a text editor or use the browser's View Source on a hosted
.svg. Look for<metadata>,<title>,<desc>,xmlns:inkscape/xmlns:sodipodi/xmlns:dc, aversionattribute, an Adobe generator comment, and inside Inkscape files,sodipodi:docnameandsodipodi:absref. - Step 2Classify each item by sensitivity — Editor namespace + version = toolchain disclosure.
sodipodi:docname/ Figma layer-path<title>= project/naming disclosure. RDFdc:creator= author disclosure.sodipodi:absref= local file-path disclosure. Rendering attributes (viewBox,fill,d) are not privacy data. - Step 3Decide your policy — For public asset libraries and marketing sites, scrub everything non-rendering. For internal-only SVGs, you may keep accessibility
<title>/<desc>. Document the policy so designers and the build pipeline apply it consistently. - Step 4Scrub the structural metadata — Run files through the SVG Metadata Scrubber. It removes all
<metadata>/<title>/<desc>and the editor namespaces/attributes on the root in your browser — nothing is uploaded. - Step 5Clear what the scrubber leaves — The scrubber does not remove XML comments (the Adobe generator line) or editor attributes on nested child elements. Follow with the SVG Pro Minifier to drop comments, the
<?xml?>prolog, and redundant namespaces. - Step 6Verify before publishing — Re-open the cleaned file's source. Confirm no editor namespace, no author record, no
docname/absref, and no leftover generator comment. Only then add it to your public bundle or CDN.
What each metadata type discloses
The privacy meaning of common SVG metadata, with whether the JAD scrubber clears it on its own.
| Metadata item | What it reveals | Cleared by the scrubber alone? |
|---|---|---|
xmlns:inkscape / xmlns:sodipodi | File was authored in Inkscape | Yes — removed from root and serialized output |
version="1.1" + <!-- Generator: Adobe Illustrator --> | File came from Illustrator (and which version) | Partly — version is removed, but the comment is not (use the minifier) |
Figma <title> like icon / nav / arrow | Internal layer/component naming, sometimes unreleased project hints | Yes — all <title> removed |
sodipodi:docname="q3-launch.svg" | Original document name, can leak project/codename | Yes if on root; child copies are not iterated |
sodipodi:absref="/Users/jane/Projects/..." | Absolute local file path → username + directory structure | Yes if on root; otherwise needs manual/minifier cleanup |
RDF <metadata> with dc:creator | Author name embedded in a Dublin-Core record | Yes — the whole <metadata> element is removed |
<desc>Created in Figma</desc> / licence text | Tool name or attribution you may not want public | Yes — all <desc> removed |
EXIF inside an embedded <image> raster | Camera, GPS, timestamps in the embedded photo | No — raster data is untouched; strip EXIF before embedding |
Risk severity by audience
How much each leak matters depends on where the SVG is published.
| Leak | Public CDN / marketing site | Internal app / design system |
|---|---|---|
| Editor + version fingerprint | Low-to-moderate (reconnaissance, professionalism) | Negligible |
| Layer/document names | Moderate (project/codename hints) | Low |
| Author name in RDF | Moderate (personal data, GDPR) | Low |
Absolute file path (absref) | High (username + directory disclosure) | Moderate |
| Embedded raster EXIF/GPS | High (PII / location) | Moderate-to-high |
Cookbook
Concrete examples of what a published SVG can disclose, read straight from the source — no special tools required.
Inkscape file leaking a local path
Inkscape's sodipodi:absref records the absolute path of a linked resource — which exposes the author's username and folder structure. This is the single most sensitive common SVG leak.
<svg xmlns:sodipodi="..." xmlns:inkscape="..."
sodipodi:docname="acme-rebrand-secret.svg"
inkscape:version="1.3">
<image sodipodi:absref="/Users/jane.doe/Desktop/ACME/logo.png"
xlink:href="logo.png" width="200" height="60"/>
</svg>
Reads as: author = jane.doe, project = acme-rebrand-secret,
tool = Inkscape 1.3. None of it renders; all of it is public.RDF metadata block with an author
A full Dublin-Core <metadata> record can embed creator, title, date, and rights. The scrubber removes the entire block in one pass.
<metadata>
<rdf:RDF>
<cc:Work>
<dc:title>Quarterly Report Cover</dc:title>
<dc:creator><cc:Agent><dc:title>Jane Doe</dc:title></cc:Agent></dc:creator>
<dc:date>2026-02-14</dc:date>
</cc:Work>
</rdf:RDF>
</metadata>
After the scrubber: the <metadata> element is gone entirely.Figma layer path in the title
Figma's <title> is the component/layer name. If your naming hints at unreleased work, that hint ships with every icon.
Before: <svg viewBox="0 0 24 24"> <title>icons / project-zephyr / beta-badge</title> <path d="..."/> </svg> 'project-zephyr' may be an unannounced product. The scrubber removes the <title>, closing that disclosure.
Illustrator fingerprint — and the honest limit
The scrubber removes Illustrator's version attribute but not its generator comment. This is the most common place people assume a leak is gone when it is not.
After running ONLY the scrubber: <?xml version="1.0" encoding="UTF-8"?> <!-- Generator: Adobe Illustrator 28.0 --> <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 48 48">…</svg> The comment still names the tool + version. Run /svg-tools/svg-pro-minifier next to remove the comment and <?xml?>.
The disclosure-free target state
After scrub + minify, a published icon names nothing about how it was made.
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M5 12h14"/></svg> No editor namespace, no version, no metadata, no comment, no layer name, no author, no file path. Safe for a public CDN.
Edge cases and what actually happens
You scrubbed but the tool name is still visible
PartialThe scrubber removes elements and root attributes, not comments. Illustrator's <!-- Generator --> and the <?xml?> prolog survive a scrub-only pass. If your threat model includes hiding the toolchain, you must also run the SVG Pro Minifier.
Author name appears in `dc:creator`
Personal dataAn author name in the RDF record is personal data under GDPR. The scrubber removes the whole <metadata> element, so this is cleared — but only run on the file you publish, and keep an internal master if you need the attribution for licensing records.
Absolute file path in `sodipodi:absref`
High riskAn absref on the root is removed (it is a sodipodi: attribute), but absref typically lives on a child <image> element, which the scrubber's attribute pass does not iterate. Verify the output: if the path is still there, remove it manually or via the minifier before publishing.
Embedded photo still carries EXIF/GPS
Not coveredIf a <image> embeds a base64 photo, its EXIF (camera, timestamp, GPS) is inside the raster, not the SVG metadata. The scrubber does not decode or alter raster bytes. Strip EXIF from the image before embedding, or reference it externally and clean it there.
Accessibility `<title>`/`<desc>` lost
Trade-offRemoving all <title>/<desc> for privacy also removes legitimate accessibility text. For meaningful icons, re-supply an accessible name in HTML after scrubbing. This is a deliberate trade-off, covered in the metadata-types reference.
Minified-by-the-designer SVG that still names a layer
Check anywayA designer's SVGO export may strip most metadata yet keep a <title> for accessibility. Do not assume an optimised file is fingerprint-free — open the source and confirm before treating it as clean.
CDN caches the un-scrubbed version
OperationalPublishing the cleaned file is only effective if the old one is purged. A CDN or browser cache may still serve the metadata-laden original. Invalidate the cache and change the asset path/hash after re-uploading scrubbed SVGs.
Comments inside a script or style block
PreservedIf an SVG contains a <script> or <style> with comments, those are not metadata and are left untouched. The scrubber is scoped to <metadata>/<title>/<desc> and editor attributes; review embedded code separately for sensitive content.
SVG referenced via `<img>` vs inlined
Same exposureWhether an SVG is served as a file (<img src>) or inlined in HTML, its source is readable. Inlining does not hide metadata — it just moves it into the page source. Scrub in both cases.
Frequently asked questions
Can someone really read metadata out of my published SVG?
Yes, trivially. SVG is plain-text XML, so saving the file and opening it in any text editor — or using a browser's View Source on a hosted .svg — reveals every <metadata> block, <title>, <desc>, namespace declaration, and comment verbatim. No special tooling is needed.
What is the most sensitive thing an SVG typically leaks?
An absolute local file path. Inkscape's sodipodi:absref can record something like /Users/jane.doe/Projects/secret/logo.png, which exposes a username, directory structure, and sometimes a project codename. Author names in the RDF dc:creator record are a close second.
Does the scrubber make my SVG completely fingerprint-free?
Mostly, but not on its own. It removes <metadata>/<title>/<desc> and root editor namespaces/attributes. It does not remove XML comments (like Illustrator's generator line) or editor attributes on nested child elements. Run the SVG Pro Minifier afterwards for a fully anonymous file.
Is leaking my design tool actually a security risk?
On its own it is low-severity reconnaissance, but it contributes to a profile of your stack. The higher risks are project/codename disclosure via layer and document names, author names (personal data under GDPR), and local file paths. Treat tool fingerprinting as housekeeping and the naming/path leaks as the real concern.
Does the scrubber remove GPS or EXIF from images in the SVG?
No. EXIF lives inside an embedded raster (<image> base64), not in SVG metadata, and the scrubber does not touch raster bytes. Strip EXIF from the photo before embedding it, or reference the image externally and clean it there.
If my SVG is inlined in HTML, is the metadata hidden?
No. Inlining moves the SVG source into the page HTML, where it is just as readable. Whether served as a file or inlined, the metadata is exposed — scrub before publishing either way.
How does this relate to GDPR?
GDPR's data-minimisation principle says you should not publish personal data you do not need. An author name in dc:creator is personal data. Scrubbing it from public assets supports minimisation. For the automation angle, see batch SVG metadata removal for GDPR.
Will scrubbing break my icon's screen-reader support?
It can, because it removes <title> and <desc> indiscriminately. For meaningful icons, add an accessible name in the surrounding HTML after scrubbing (e.g. aria-label), or mark decorative icons aria-hidden="true". The trade-off is detailed in the metadata-types reference.
Is anything uploaded when I clean a sensitive SVG?
No. The scrubber runs entirely in your browser DOM — the file never reaches a JAD server (the result panel shows a 0 bytes uploaded badge). That matters when the very thing you are removing is sensitive: it is never transmitted in the first place.
How do I verify the file is actually clean?
Open the cleaned SVG's source and search for xmlns:inkscape, xmlns:sodipodi, <metadata, <title, dc:creator, docname, absref, and Generator. If any remain (typically the generator comment or a child absref), clean them with the SVG Pro Minifier or manually.
Do optimised SVGs from designers still leak?
Sometimes. SVGO and tool 'optimised SVG' exports often keep a <title> for accessibility or leave a comment. Never assume an optimised file is fingerprint-free — inspect the source before treating it as safe to publish.
Which tools should I combine for a clean public asset?
Scrub structural metadata with the Metadata Scrubber, drop comments and the prolog with the SVG Pro Minifier, and optionally cut size further with the SVG Precision Tuner and SVG Unused Defs Purger.
Privacy first
Every JAD SVG tool runs entirely in your browser using the DOM API and Canvas. Your SVG files never leave your device — verified by zero outbound network requests during processing.