Research - 8 min read
What Our PPTX Security Fixture Kept—and Rejected
A first-party PPTX rendering test showing which safe slide elements survived, which active or remote elements were rejected, and what the result does not prove.
By QuickerConvert Team (organizational author) - Published
A presentation can contain more than the shapes and text visible on a slide. Relationships can point outside the file, embedded SVG can contain active markup, and a misleading file extension can hide unexpected bytes. On July 17, 2026, we tested QuickerConvert's Browser visual PPTX renderer with a controlled one-slide fixture built specifically to combine safe slide content with active and remote probes. The goal was not to claim that one test makes every presentation safe. It was to verify the boundaries we actually enforce.
We generated the fixture ourselves
The fixture was created by scripts/tests/generate-pptx-security-fixture.mjs in the QuickerConvert repository. It contained a normal slide title, a safe rectangle, circle, and text, plus an embedded SVG with an event handler, script, iframe, object, external image, and remote probe URLs. The slide relationships also included a mixed-case external image relationship and a JavaScript hyperlink. Because it was synthetic, the test used no customer document, private data, proprietary deck, or third-party artwork.
- One generated PPTX with one slide.
- Safe controls: ordinary drawing shapes and text.
- Unsafe probes: active markup, remote loading, and a JavaScript link.
- Fixture purpose: regression testing, not exploit distribution.
The browser path sanitizes before rendering
The active renderer converts supported slide content into SVG, passes the complete markup through sanitizeSvgMarkupForRendering, and only then creates the Blob used for raster output. The allowlist excludes executable container elements, removes event attributes, blocks document types and entities, rejects unsafe URLs, and limits markup size. Image relationships must be local image relationships, and supported raster bytes must match the declared PNG, JPEG, GIF, or WebP type before they are used.
- External relationship mode is blocked even when its case is unusual, such as eXtErNaL.
- A file named .png is rejected if its bytes do not have a PNG signature.
- Raster data images can be retained; embedded SVG data URLs are not accepted as raster images.
- The renderer no longer uses the removed legacy main-document rendering path.
Safe visual content survived the test
After sanitization, the safe shape identifier, rectangle styling, circle, and the text Sanitized SVG remained available to the renderer. In the manual browser check, the fixture produced a usable one-page visual PDF. This matters because a sanitizer that deletes every element would be safe in a narrow sense but useless as a presentation converter. The intended behavior is to preserve supported visual content while refusing active or remote behavior.
- Kept: supported local shapes, fills, strokes, text, local fragments, and matching raster data.
- Rendered result: one readable page from the controlled one-slide deck.
- Tradeoff: unsupported or active content can disappear from Browser visual output.
Active and remote probes did not survive
The automated assertions found no script element, event handler, iframe, object, embed, JavaScript URL, attacker.invalid URL, remote background URL, or external relationship in the sanitized rendering input. A disguised SVG presented as a PNG was also rejected because the bytes did not match the extension. Seven security-focused tests covered sanitization, local data images, entity and size rejection, raster signatures, relationships, the allowlist, and active renderer integration.
- Removed or ignored: script and onload behavior.
- Removed or ignored: iframe, object, embed, and active link containers.
- Removed or ignored: external images, remote CSS URLs, and external PPTX image relationships.
- Rejected: raster filenames whose byte signatures did not match.
A security pass can reduce visual fidelity
Browser visual conversion is appearance-first, but it does not promise to reproduce every PowerPoint feature. Remote media, unsafe SVG, unsupported image formats, animations, audio, video, embedded objects, unusual fonts, and complex effects may be missing or simplified. That is a deliberate tradeoff when the browser renderer cannot safely or faithfully reproduce a feature. For an important deck, compare the exported first slide, a media-heavy slide, and the last slide against the source.
- Use Accurate local mode when Office-style layout fidelity matters most and the Windows helper is available.
- Use Browser visual for a quick static reading copy when its limitations are acceptable.
- Never assume a converted PDF preserved animation, interactivity, speaker notes, or embedded media.
What this fixture does not prove
This was one synthetic fixture and seven targeted regression tests. It does not prove that QuickerConvert detects malware, safely handles every malformed ZIP or XML variant, reproduces every safe PowerPoint feature, or replaces endpoint security. It also does not test the separate Accurate local PowerPoint conversion path. New parser behavior, browser APIs, and file variants can introduce different risks, so the sanitizer and fixtures need continued review.
- Not an antivirus or malware classification test.
- Not a representative corpus of real-world presentations.
- Not a performance benchmark.
- Not evidence that every rejected element was malicious; some are unsupported because they create unacceptable rendering risk.
Conclusion
The controlled result is narrow but useful: supported shapes and text remained, while the active and remote probes we planted were removed, ignored, or rejected before rendering. Choose Browser visual when a static appearance-first copy fits the task, choose Accurate local when layout fidelity matters, and review the exported PDF either way.