Blog Post

Handling Browser Support of Media Files in PSPDFKit for Web

Veronica Marini
Illustration: Handling Browser Support of Media Files in PSPDFKit for Web

The PDF specification allows embedding a video or an audio file into a PDF document using rich media annotations. This annotation type is supported in our iOS, Android, and Web SDKs and can be created with Adobe Acrobat and other similar tools.

In PSPDFKit for Web, the video or audio file embedded in a document is displayed in a <video> HTML element. According to the MDN guides, this <video> HTML element embeds a media player that supports video playback in the browser. The newest version of HTML is HTML5, and currently, HTML5 video is the only widely supported video playback technology in modern browsers, especially since Adobe no longer supports Flash Player.

The <video> element is particularly nifty. Similar to audio and image elements, it takes a path to the media element you want to display, and thanks to the controls attribute, you can decide if you want the browser’s default video controls to show. If you’re interested, you can read the full list of attributes the <video> element can receive.

The Problem

PSPDFKit for Web introduced support for media annotations in version 2022.4. The problem the Web team faced with this task was that video and audio format support varies among browsers. The <video> element doesn’t specify which video or audio format a browser should support, and so we decided to be as agnostic as possible by accepting any MIME type. This left us with the possibility that a certain video or audio file embedded in a media annotation might not be supported by the browser.

Possible Solutions

We had three possible solutions to address this:

Browser Sniffing

Browser sniffing means to check if the current browser supports the provided media format by looking it up in a list that maps browsers to media MIME types. This approach is error prone, as any current knowledge about browser support will inevitably be incomplete and/or not up-to-date at some point. Moreover, the MIME type information may not always be available for checking, even for supported media types.


Another option is to use HTMLVideoElement.prototype.canPlayType by including it in the file used for checking if a media file can be played:


This function returns a string that tells you how likely a media type is to play on a specific browser. The three possible results are:

  • "" — An empty string that means the media cannot be played on the current browser.

  • probably — The media is likely playable.

  • maybe — There isn’t enough information to determine whether the media can play (until playback is actually attempted).

Showing an Error

The final option is to let the browser show an error if the MIME type isn’t supported.

This is what we used for PSPDFKit for Web, and it was the best solution for two reasons:

  • It aligns to the video experience a user can get in other environments on the browser; adding an ad-hoc UI could potentially be a misleading experience for end users who expect something else.

  • There are edge cases where the MIME type information may not be present, so canPlayType() wouldn’t cover all situations and could potentially fail to reproduce a video even when the browser would’ve supported the format.

Video Poster Attribute

In the event of a video not being supported by the browser, you can define fallback logic to show an image that says the video format isn’t supported. This is done by using the <video> element poster attribute:

// If (canPlayType('my-video-type') === '' ||
canPlayType('my-video-type') === 'maybe')

	<source src="/my-video.mp4" type="video/mp4" />
	Sorry, this browser doesn't support the video element.

The content inside the opening and closing <video></video> tags will be the fallback in browsers that don’t support the element, although almost all browsers (and at least all predominant browsers) support <video> elements.

Wrapping Up

Developing a web product always poses unexpected challenges due to the browser, and in this blog post, we wanted to give a glimpse of how we approach these kinds of issues.

Please email us if you’re interested in PSPDFKit for Web. For a complete list of features, visit our product page. We’d love to hear about your use case and discuss how to best implement it.

Veronica Marini Web Engineer

Veronica’s passion for puzzles got her into programming. She likes everything frontend, bringing design to life, and measuring herself with coding. She also collects hobbies: from yoga to surfing to playing Brazilian drums.

Related Products
Share Post
Free 60-Day Trial Try PSPDFKit in your app today.
Free Trial

Related Articles

Explore more
DESIGN  |  Baseline UI • Web

Part V — Mastering the Baseline UI Theme: An In-Depth Exploration

DESIGN  |  Baseline UI • Web

Part IV — Building Consistency: A Guide to Design Tokens in Baseline UI

DESIGN  |  Baseline UI • Web

Part III — Accessible UI Design: Building Inclusive Digital Experiences