Microsoft 365 supports SVG. It says so in the documentation, it works in the Insert dialog, and the file format appears in the supported types list. What the documentation does not say is that SVG support in Word is partial — and has been partial, in essentially the same shape, since the feature first shipped in 2017.

If your SVG looks correct in a browser, in Inkscape, or in Illustrator, but renders wrong, partially, or not at all in Word, you have not done anything wrong. You have run into the boundary of what Word actually implements from the SVG specification. That boundary is narrower than most people expect, and the workarounds are specific.

What Word actually supports

Word’s SVG engine is essentially a static-shape renderer. It handles the parts of SVG that look like vector illustration:

  • Paths — straight lines, curves, the geometry primitives. These render reliably.
  • Basic fills and strokes — solid colours, stroke widths, dash patterns. These work.
  • Basic transforms — scale, rotate, translate applied to elements. These work.
  • Simple linear gradients — two-stop linear gradients with the standard <linearGradient> definition render correctly in most cases.
  • Text as outlines — text that has been converted to paths in the source file (Object → Path in Inkscape, or “Create Outlines” in Illustrator) renders correctly because it has stopped being text.

That covers a meaningful portion of practical SVG content — logos, icons, simple illustrations. It does not cover much of the SVG specification.

What fails or renders wrong

The list of SVG features that break in Word is consistent across builds and worth memorising if you produce SVG artwork that will be consumed in Office documents.

SVG filters. Anything inside a <filter> element. feGaussianBlur, feDropShadow, feColorMatrix, the whole filter primitive family. Word strips or ignores these, so the artwork renders as if the filters were never there. If your logo has a soft shadow built with feDropShadow, the shadow disappears in Word and the logo looks naked.

Complex gradients. Radial gradients with a focal point offset from the centre (the fx and fy attributes) often render with the focal point reset to the centre. Sweep gradients — a feature being standardised in SVG 2 as of 2026 — are not supported. Mesh gradients are not supported. Conic gradients (CSS-based, sometimes used in inline-styled SVGs) are not supported. The fallback is usually a flat colour or a degraded gradient that does not match the original.

Embedded fonts. SVG can embed fonts inline using <font> elements or data: URIs. Word does not honour these. Text in an SVG that relies on an embedded font gets substituted to a system font, often with visible spacing and weight changes. The fix is to convert text to outlines in the source before saving the SVG.

Patterns and <pattern> fills. Repeating pattern fills referenced via <pattern> definitions are inconsistent — some render, some don’t, depending on how the pattern is constructed. Hatched fills produced by Illustrator’s pattern feature usually fail.

Animations and scripts. Any <animate>, <animateTransform>, or <script> element is silently stripped. The SVG inserts as a static snapshot. This is intentional — Word is not a browser — but the failure mode is silent, so designers who hand off animated SVGs don’t know their animations were lost.

Clip paths and masks. Simple clip paths usually render. Complex masks with gradient-based alpha often do not.

External references. SVGs referencing external resources via <image href="..."> to a remote URL do not load the external image. The file must be self-contained.

”Convert to Shape”: Word’s superpower for SVG

This is the part of SVG support that is genuinely useful and that most people don’t know about.

Insert an SVG into Word, right-click the image, and you see a Convert to Shape option. Click it. The SVG becomes a native Office shape — recolourable, editable, fully scalable, and rendered by Word’s own shape engine instead of the SVG decoder.

Once converted to a shape:

  • You can recolour individual elements using the Office colour palette.
  • You can resize without quality loss.
  • You can apply Office shape effects (shadows, glows, 3D rotation) that work reliably.
  • You can ungroup the shape and edit individual paths.

This is the fix for a large category of SVG rendering problems. If your SVG is icon-style artwork without filters or complex gradients, Convert to Shape gets you into a format Word handles natively, with all of Word’s drawing capabilities available.

The trade-off: once converted, you cannot easily go back to SVG. The shape is now a series of Office drawing primitives, and exporting it back to SVG (via copy-paste to a vector editor) produces a flattened, simplified version of the original. Convert to Shape is one-way.

The EMF workaround for complex artwork

When the SVG contains features Word cannot render — filters, complex gradients, patterns — and Convert to Shape would lose the appearance, the reliable workaround is to convert the SVG to Enhanced Metafile (EMF) before inserting.

EMF is Microsoft’s native vector format. Office apps render EMF using a completely different code path than SVG, and that code path is significantly more capable for the kind of effects designers actually use. A soft drop shadow that Word ignores in SVG will render correctly when the same artwork is delivered as EMF.

The conversion can be done with:

  • Inkscape. File → Save As → Enhanced Metafile (.emf). Free, open source, runs on Windows/Mac/Linux. Best results for designer-produced SVGs.
  • Online converters. Convertio, FreeConvert, AnyConv, and similar all handle SVG-to-EMF. Quality varies — test before relying on them for client work.
  • Illustrator export. File → Export → Export As → Enhanced Metafile. Generally clean output but can struggle with very complex gradient meshes.

Once you have the EMF, insert it through Insert → Pictures → This Device the same way you would insert an SVG or PNG. The EMF scales without rasterisation, prints sharply, and renders effects that SVG version did not.

The limitation: EMF is a Windows-specific format. If the document will be opened in Word for Mac or Word for the Web, EMF rendering can be flaky or fall back to a rasterised version. For cross-platform documents, EMF is not the answer.

When to rasterise instead

For some artwork, the best answer is to stop trying to preserve vector and instead deliver a high-resolution raster. This is unsexy but pragmatic.

Rasterise to PNG at 300 ppi (or higher for print) when:

  • The artwork will only be viewed at a known fixed size.
  • The artwork uses effects Word cannot render and EMF is not viable.
  • You need guaranteed consistent appearance across Word for Mac, Word for the Web, and Word for Windows.
  • The document is being distributed and may be opened in unknown contexts.

The downside is that a raster cannot be resized without quality loss, but for documents that will not be resized after creation, that downside is theoretical.

Cross-version differences

SVG behaviour is broadly consistent across Microsoft 365 Word (current channel), Word 2021, and Word LTSC. The same features render, the same features fail. The differences are at the margins:

  • Word 2019 and earlier handle SVG less reliably than M365. If your audience is mostly on perpetual licence versions, assume the EMF or PNG fallback path.
  • Word for Mac has slightly worse SVG fidelity than Word for Windows for the same file. Mac-specific rendering bugs exist around gradients and text-on-path.
  • Word for the Web renders SVGs but does not support Convert to Shape. The web client treats SVGs more like static images.

The SVG support story is broadly similar in PowerPoint and Outlook, but with app-specific quirks. The comparison piece SVG behaviour across Office apps lays out the differences side by side.

What to do when an SVG insert fails entirely

If Word produces an error rather than rendering badly — typically the “Word cannot insert the picture from the specified file” dialog or a silent failure where the image area appears blank — the issue is usually not the SVG content but file path, permissions, or the file itself. The Word cannot insert the picture from the specified file walkthrough covers the dialog and the diagnostic order.

If the SVG inserts but renders as a broken image placeholder, the file is corrupt or uses XML that Word’s parser cannot handle. Open the SVG in a text editor (it is XML, so any editor will do) and look for malformed tags, missing closing elements, or characters that should have been entity-escaped. Many automated SVG generators produce technically-invalid XML that Word rejects while browsers tolerate.

The honest summary

Word’s SVG support is a useful feature within a narrow band of artwork — flat illustrations, icons, simple logos without effects. Outside that band, you are working around a partial implementation that has not been substantially improved in years.

The practical approach: design SVG artwork for Office consumption with the boundary in mind. Avoid SVG filters, complex gradients, embedded fonts, and animations if the artwork will live in a Word document. When you cannot avoid them, deliver the artwork as EMF instead. When even EMF is not viable, deliver a high-resolution PNG and accept that you have given up the vector advantage.

Microsoft will not be fixing this. SVG support in Word has been in its current state long enough that the absence of improvement is itself the signal. Plan accordingly.