Use a verified authorized original through a reviewed upload and rendering route, preserve contextual restrictions, and choose a permitted raster alternative if the vector cannot be faithfully supported.
Choose the publishing context before treating an SVG as an ordinary image upload. A vector can be accepted by one route, modified by processing and rendered differently in another context. File extension, visual appearance and a successful upload are separate pieces of evidence, not a general safety certificate.
This guide concerns website artwork, including logos and icons. It uses a fictional community directory and does not claim a sanitizer test or security audit. The aim is a faithful, maintainable publishing route, with a permitted raster alternative when the intended vector cannot be supported safely.
Start with the authorized original
For a brand logo, obtain the intended asset from the brand’s verified source or an authorized supplied pack. Record the relevant usage conditions and version. Do not recreate a mark with AI, recolor it to suit a theme or use an unrelated search-result preview as the master file.
Keep the received original unchanged in protected working storage. A file described as a logo can still have an unexplained source or content. If provenance is unclear, obtain a fresh official asset before trying to make it render. Our image permissions and credit guide covers that separate rights decision.
In the fictional directory, a supplier sends a vector and a permitted PNG. The editor should record both as supplied alternatives, rather than repeatedly editing the vector until its shape happens to resemble the preview.
Distinguish an image from an embedded document
MDN’s SVG image guide explains that image contexts can restrict scripting and external resources. Those restrictions differ from directly viewing the file or embedding it as a document. Do not assume that using a file in an image element makes its separate public address harmless in every context.
Identify the actual use: a normal image, CSS background, inline markup or an embedded document. Ask the maintainer to review the route you intend, including whether the original file is publicly reachable. Changing context just to make missing features appear can also change the security assumptions.
| Stage | Evidence needed | What it cannot establish alone |
|---|---|---|
| Source acquisition | Verified original and permitted use. | The site’s upload processing covers it. |
| Upload acceptance | Approved route and effective type policy. | The bytes were sanitized. |
| Published file | Expected processed output and response. | Every browser/context renders it identically. |
| Page rendering | Faithful artwork in the intended element. | Other access paths have equivalent restrictions. |
Ask what the upload route actually does
Separate three responsibilities: deciding who may upload a type, sanitizing file content and optimizing size. A MIME allowlist or familiar filename answers neither of the latter questions. Likewise, making an SVG smaller does not establish that active or unsuitable content was removed.
The Safe SVG publisher documentation provides a concrete example of these distinctions: it describes sanitization, user restrictions and separate SVGO optimization, while acknowledging that arbitrary third-party upload actions cannot all be covered. That is a scope limitation to investigate, not a reason to enable more upload routes.
Ask who owns the specific uploader and whether imports, editor uploads and custom integrations follow the reviewed processing path. “We installed an SVG tool” is incomplete if a separate import bypasses that path. No sanitizer should be described as a guarantee for every input, future version and surrounding integration.
Review the published result without executing unknown content
Give the responsible maintainer the original asset, intended context and safe reproduction description through approved storage. Have them compare the received and processed output with appropriate tooling. Do not open an unexplained file as an active document in the production environment just to see whether it contains something interesting.
For a missing image, record the actual final address, response and rendering element. Confirm that the address identifies the expected asset rather than an error page, expired private route or different file. Keep authentication details and signed URLs out of the shared diagnostic record.
If the expected file arrives, investigate its geometry and supported features next. Avoid disabling response protections or weakening the entire upload policy while guessing at the cause.
Separate empty space from damaged artwork
The viewBox reference describes the internal area mapped into a viewport; nonpositive width or height prevents rendering. A missing viewBox does not universally imply a zero-size image. Review dimensions, coordinate bounds and the actual artwork together.
For the directory example, a logo might arrive with large transparent margins, while another might lose a shape after processing. These are fictional possibilities, not observed failures. Centering the container may help layout; it cannot restore removed artwork or identify why a vector is blank.
Record which stage first changes the appearance. If the approved original is correct but the processed result differs, return that comparison to the integration owner. Do not hand-edit a protected brand asset to imitate what you think was removed.
Understand the WordPress upload boundary
The current base WordPress MIME mapping does not provide arbitrary SVG uploads. The effective allowed-type function accounts for user and filter behavior, so extensions and routes can differ. Allowing a MIME type does not sanitize the file’s content.
Do not rename an SVG to another extension, grant unrestricted uploads or paste an allow-everything filter to defeat a refusal. Ask which maintained workflow is intentionally supported on that installation. A refusal can be a valid policy boundary rather than an error requiring a workaround.
Also distinguish Media Library uploads from the WordPress 7.1 registered icon API. That API admits a restricted subset of SVG elements and attributes; unsupported markup can be stripped. Successful registration does not guarantee that a later file read produces visible artwork. It is not unrestricted support for every supplied logo.
If a mark needs unsupported features to remain faithful, use a permitted alternative instead of removing safety filtering. A developer’s icon system and an editorial brand-image workflow are different jobs.
Choose and verify a faithful raster fallback
Prefer an approved raster asset from the same authorized pack. If conversion is permitted, use a controlled workflow and compare the result with the original, including transparency, clear space and small-screen legibility. Do not assume a conversion preserves every fine feature or grants new brand-use rights.
Check the image at the actual displayed sizes and backgrounds. A logo that looks correct on white may disappear against a dark card. Preserve the official color treatment and choose a compatible container, rather than changing the mark. Our complete image-compatibility journey covers delivery checks beyond the filename.
Finish with a route somebody can maintain
Record the authorized source, approved context, uploader, processing owner, published result and fallback. Check that later editors know which asset and route to reuse. A successful visual check today does not replace review when the upload integration or source asset changes.
Keep specialized jobs separate. For inbox logos, BIMI has its own receiver and certificate requirements; a website SVG that looks correct is not automatically suitable there. The useful outcome here is faithful website artwork through an explained processing and rendering path.
Sources and verification
Editorial review 2026-10-15. Source check dates are recorded separately. Notes describe what each source supports and its limits.
View sources
- MDN: SVG as an imageChecked Image-context restrictions differ from direct viewing and document embedding, including scripting and external resource limits.
Limits: Behavior is contextual and browser-dependent; an image-context restriction is not proof that the publicly reachable file is harmless in every other context. - MDN: SVG viewBox attributeChecked Internal coordinate area and mapping, including nonpositive width or height suppressing rendering.
Limits: A missing viewBox does not universally mean an SVG has zero visible pixels; dimensions and artwork need contextual inspection. - WordPress wp_get_mime_types referenceChecked Current base MIME mapping does not provide arbitrary SVG Media Library uploads.
Limits: Base types do not establish effective allowed uploads for every user, extension or upload route. - WordPress get_allowed_mime_types referenceChecked Effective allowed upload types can be affected by user and filtering.
Limits: Allowlisting a type is a permission decision rather than sanitization of the file content. - Safe SVG publisher documentationChecked Publisher distinguishes SVG sanitization, upload-user restrictions, SVGO optimization and limits covering arbitrary third-party upload actions.
Limits: Used as a concrete scope example, not a product test, recommendation or guarantee that all routes receive sanitization. - WordPress 7.1: registering and rendering SVG iconsChecked Restricted registered icon API and conservative elements/attributes; registration and later file rendering are different stages.
Limits: Not general unrestricted SVG Media Library support or a complete implementation of every SVG feature.