Limitations

Read this before adopting

pptx-viewer covers a large surface of the OpenXML specification, but some things are approximated, read-only, or bounded by the browser platform. This page records known limitations; it is not an exhaustive compatibility guarantee for every Office feature or third-party extension. Check data.warnings after loading a deck and see OpenXML conformance for the formal coverage manifest.

Core engine (pptx-viewer-core)

Feature	Status	Notes
.ppt export	Partial	Ink, SmartArt, charts and 3D models reopen in PowerPoint as editable objects through an embedded OOXML round-trip package, and every picture format is embedded the way PowerPoint's own 97-2003 save does it (PNG, native EMF/WMF, DIB, SVG rasterised); the master carries the deck's title, body and other text styles, its placeholder shapes (title, body, date, footer, slide number) and its theme, so PowerPoint reports the deck's own master styles, theme colours and fonts; groups, tables (written as a group of cell rectangles, as PowerPoint 2003 does) and files over 7 MB open (all verified by reopening in PowerPoint over COM). Video and non-WAV audio are written as their poster picture, which is exactly what PowerPoint's own 97-2003 save produces. An SVG picture with no raster fallback is rasterised in a browser and, through the optional @napi-rs/canvas peer, in Node.js (a placeholder only where neither is available). Password-protected .ppt files PowerPoint writes (RC4 CryptoAPI) open with their password, and an encrypted .ppt this writer saves opens in PowerPoint. Still open: only the first slide's master is written, so a deck with several masters gets that one on every slide, and a GIF picture's first frame is stored as a PNG (as PowerPoint's own 97-2003 save does) but uncompressed, so a large GIF makes a much larger file than PowerPoint writes. See OpenXML conformance.
SmartArt layout	Approximate without cached drawing	Decks saved without the cached dsp:drawing are laid out by a per-point DiagramML engine (143 layouts) or the older family interpreter. Against 229 COM-authored gallery fixtures, 228 produce PowerPoint's set of shapes, 143 match its geometry within 1% (181 within 5%) and 129 match every font size. Name and Title Organization Chart, the labelled and table hierarchies, horizontal org charts with assistants and three layouts (Arrow Ribbon, Balance, Varying Width List) remain inexact. See OpenXML conformance for the measurement evidence.

Animation authoring

An effect authored in the animation panel is reconciled into the slide's existing p:timing tree; the deck's own effects are left byte-identical. Known gaps:

• Directions cover the edge and corner variants only. Every entrance and exit is saved with PowerPoint's own behaviour tree for its preset and direction, and changing an existing effect's preset or direction rebuilds that tree while a new duration retimes it (reopened in PowerPoint over COM, its own render matches PowerPoint-authored effects frame for frame). The direction picker offers exactly the variants PowerPoint has: all eight for Fly and Crawl, the four edges for Wipe, Peek and Stretch (React's picker has no corner options yet, so it offers only the four edges for Fly and Crawl). Split, Zoom, Blinds and the shape reveals keep their default variant, Float In has no direction (Float Up and Float Down are separate presets), and Blink is an approximation.
• Some presets are approximated on playback. Entrance and exit effects play the deck's own behaviour tree: its formulas, each behaviour's own timing and easing, motion paths at an even pace along their length, fades and wipes, so Fly starts just off the slide edge as PowerPoint's does. Compared frame by frame with PowerPoint's CreateVideo render of 116 preset and direction variants (a 200 pt shape over 2 s), the visible shape stays within about 15 px of PowerPoint's on average; Swivel and Faded Swivel differ only at the instant their width crosses zero, and Arc Up drifts up to 75 px early in its curve. Still approximated: Color Typewriter plays a substitute, the Box, Circle, Diamond and Plus exits ignore their direction, and emphasis effects use preset keyframes.
• Partially supported: a p14:bounceEnd of 100% (no travel left, which PowerPoint itself renders erratically) is clamped to 95%. Media-bookmark triggers ("On bookmark"), the p15 transitions with their direction options, and the Zoom transition's In/Out direction are authored in all five bindings, and the Bounce End settle curve is fitted to PowerPoint's own frames.

Detecting gaps at runtime

You do not have to guess whether a file hit a limitation. The load pipeline reports many unsupported or approximated constructs (not all: animation substitutes, for example, raise no warning) on data.warnings, typed as PptxCompatibilityWarning:

interface PptxCompatibilityWarning {
	code: string; // stable machine-readable code
	message: string;
	severity: 'info' | 'warning';
	scope: 'presentation' | 'slide' | 'element' | 'save';
	slideId?: string; // present for slide/element-scoped warnings
	elementId?: string;
	xmlPath?: string; // where in the package the construct lives
}

Check data.warnings after load() (and after save()) if your application needs to surface fidelity notices to users or gate features per file.

See Runtime Environments for where each part of pptx-viewer runs (browser / Node.js / Web Worker) and platform-specific behaviour that follows from the browser sandbox rather than from a missing feature.

Framework viewers (React, Vue 3, Angular, Svelte 5, Vanilla JS)

CSS-based rendering trades some visual effects for fidelity elsewhere

Slides render as HTML/CSS rather than Canvas, giving sharp text at any zoom, native accessibility, and DOM interactivity. The tradeoff is that a few PowerPoint effects have no exact CSS equivalent and are approximated.

Visual effect approximations

Effect	Status	Notes
3-D shapes and scenes (a:sp3d / a:scene3d)	Metal residual	Metal materials used to wash out under high-elevation light rigs; the specular light now has its own capped elevation, re-fit against 134 PowerPoint renders (mean absolute error 75.0 to 36.4 on a 0-255 scale), so a smaller residual remains. The 2026-09-16 relaxedInset/slope/hardEdge bevel fix has not yet been re-verified against a fresh PowerPoint render. See Visual Effect Fidelity for the provenance.
WordArt envelope warps (inflate / deflate / can / slant / fade / cascade / ...)	Can presets inexact at some depths	Glyphs are placed by arc length along the top and bottom curves. Re-measured against PowerPoint Slide.Export (1920 px wide, Noto Sans, Verdana and Arial, 2026-09-25): the can presets score ink IoU 0.94-0.97 with a mean contour error of 0.8-1.7 px (95th percentile 1.5-6 px) at most depths, and inflate / deflate 0.96-0.97. At 9 of 20 swept adj values (textCanUp 80000-93333, textCanDown 3333-23333) PowerPoint ends one or both text rows about 1.2% of the box width short and leans the glyphs; that is not modelled (IoU 0.73-0.86 there). Fonts whose file is not obtainable use an outline traced from the browser's own rendering, which agrees with the real font file to within 0.002 IoU. See Visual Effect Fidelity.

Reflections, soft edges and path gradients are also approximations, but hold up well against real PowerPoint; see Visual Effect Fidelity for the technique and the COM-measured evidence behind each one.

Known rendering and editing gaps (2026-09 audit)

A September 2026 audit against real PowerPoint found these gaps that are still open:

• Saving an edited slide can still touch minor markup. Equations, line breaks, inherited formatting, master text styles, theme backgrounds, comment timestamps, picture fills, media click actions, run languages and properties, ruby runs, outline widths, inner-shadow colours, gradient insets, bullet colours on an inherited bullet, tab alignment, animation and audio metadata and untouched charts round-trip, and docProps is refreshed on save as PowerPoint does. An empty <a:pPr/>, a bare <a:p/>, notes endParaRPr and prstTxWarp/avLst survive a rewritten slide, and the Words and Paragraphs counts in docProps/app.xml are recomputed from slide, notes and SmartArt text the way PowerPoint counts them (COM-verified). A small residue remains on a rewritten slide: an empty <a:extLst/> on a picture and a video's showWhenStopped flag can be dropped. Unedited slides round-trip cleanly.
• Charts: when outside pie labels at the bestFit position collide, PowerPoint nudges them apart and draws leader lines to the nudged ones; that is not modelled. A pie with an automatic plot area is also drawn slightly larger than PowerPoint draws it (up to about 8% in a small chart). A data label that shows the category name and the percentage with no c:separator is drawn on one line joined by ", ", where PowerPoint puts them on two lines.
• 3D models ignore the camera, transform and lights authored in PowerPoint.
• Editor coverage is a subset of PowerPoint's. The ribbon style galleries (Shape Styles, Shape Effects, WordArt Styles, Picture Styles, the Bullets and Numbering libraries, Table Styles, Chart Styles, Chart Colors and Quick Layout, SmartArt Styles and Change Colors, and the Design > Variants Colors and Fonts) and the contextual Shape Format, Picture Format, Table Design, Chart Design and SmartArt Design tabs are available in all five bindings; the Variants Effects and Background Styles galleries, SmartArt Design > Layouts and Picture Format > Corrections, Color and Artistic Effects have no ribbon gallery yet (picture adjustments and the SmartArt layout are set from the inspector). Edit Points (with the Freeform: Shape and Curve drawing tools), Merge Shapes, on-canvas picture cropping (crop handles, Crop to Aspect Ratio, Fill, Fit), Paste Special, the empty-canvas and element context menus, slides-pane multi-select, real in-place animation preview and the standard editing shortcuts are available in all five bindings.

EMF/WMF metafiles (emf-converter dependency)

Not this repository's code

emf-converter is a separate npm package with its own repository; pptx-viewer-core only consumes it. The table below records what that package does today, so treat its own release notes as authoritative if the two ever disagree.

Canvas API required

Metafile conversion needs OffscreenCanvas or HTMLCanvasElement. Pure Node.js without a canvas polyfill is not supported for EMF/WMF images (the rest of the core engine runs fine in Node).

Feature	Status	Notes
Gradient and texture brushes	Resampling residual	Gradients, pattern brushes and EMF+ texture brushes (including compressed bitmaps, since 3.3.0) render with exact stops and tiling; the browser's pattern filtering leaves a small edge-smoothing difference from Windows GDI+ (measured in the package README).
Raster operations	Exact	All 256 ROP3 codes and all bitwise ROP2 pen modes, including inside BeginPath/EndPath paths (since 3.3.0), evaluate exactly.
Text and transforms	Browser font engine	Glyph metrics can differ from Windows GDI: ExtTextOut dx arrays, the LOGFONT height sign and escapement are honoured, but without a dx array spacing depends on the browser's font substitution. Rotated and sheared world transforms apply to shapes, blits and text (since 3.3.0); text under a skew uses a single rotation angle.

Related reading

• Introduction - what the project supports overall.
• Architecture - why these tradeoffs exist.
• OpenXML conformance - the formal definition of "supported" used by the coverage manifest.
• Visual Effect Fidelity - CSS/SVG effect approximations confirmed against real PowerPoint.
• Runtime Environments - where each part of pptx-viewer runs, and browser-sandbox platform notes.