Skip to content

24 ways to impress your friends

“Probably, Maybe, No”: The State of HTML5 Audio


Comments are ordered by helpfulness, as indicated by you. Help us pick out the gems and discourage asshattery by voting on notable comments.

Got something to add? You can leave a comment below.

David Calhoun

Great article! Nice to see some attention being paid to the Audio tag (Video seems to have gotten all the attention these days).

From some feature tests I’ve run, it looks like Audio is supported by Android – I wonder what sort of quirks await us there?

Do you have any test pages up for folks who would be interested? You can be the next PPK.. for audio ;)


It’s interesting to note that reading through the entries on 24ways so far, Firefox seems to really be leading innovation. Yes, Jaegermonkey might not be as fast as v8, but things like the audio data API, -moz-calc(), -moz-any(), support for ES5 Harmony, etc. are, in my opinion at least, more important. :)

Walt Ribeiro

As a musician, using the audio tag and the HTML5 vs. Flash setup was a drag.

I agree, native audio support is the future – but I’ve decided that it’s too soon to worry about right now until everyone and every browser ‘catches up’.

Remy Sharp

One fairly significant bug I’ve found that’s apparent in most browsers:

- audio (and video) http request aren’t sent the referrer header.

So if someone decides to start hotlinking your content – which can be rather large with audio and video, there’s no way to control your bandwidth use.

I’m not against sharing content, but I’ve been caught out where a massive web site starting linking to my videos and took my server down.


This is still a great relevant article concerning the <audio>.

It is sad to see the warring formats still raging on today. Just completed an audio heavy website and converting .mp3 to .ogg just for browser support was taxing to say the least!

Tab Atkins

Note: if a browser returns “no” for .canPlayType(), it’s an old implementation. The spec currently requires the empty string for “I know I can’t play this” (because the empty string is == false, so testing for the value is easy).

The other two values, “maybe” and “probably”, are indeed pretty weird, but they’re a direct result of the weirdness surrounding audio formats and containers. To put it simply, it’s nearly impossible to tell if you can actually play a given file without just passing it to your decoder and seeing if it throws an error.

So, at best browsers can offer a “probably” for when they’re pretty sure a particular file is playable. “maybe” is for the even more uncertain cases, like when you specify the type as a container format without giving the codec. The browser may support decoding the container, but without more knowledge it can’t give you an answer as to whether the file itself is playable.

So, yeah, it’s kinda weird, but it’s a good compromise with reality. Just remember that the “I know I can’t play it” case can just be treated like it returned false, as long as you’re not using ===. Something easy like “if( (new Audio()).canPlayType(type) ) {…}” will work fine.


The reason audio and video tags were not implemented in early html/etc (in my guess) is because it wasn’t realistic to even consider under the dial-up bandwidth of the time. Audio and video files take a lot of bandwidth, of course.

I remember when downloading a 5meg file took anywhere from 15 to 45 minutes, depending on network conditions.

YouTube would not even function on dial-up. It was the dark ages, for sure. ;)

Scott Schiller

Thanks, all, for the comments.

David: I believe HTML5 audio is in the “Gingerbread” (Android 2.3) release. Re: Test pages, it might not be a bad idea to put together a table of common canPlayType() sort of calls.

Tab: Good point re: canPlayType() and “no” responses; in testing I saw a mix of “no” and “”. The latter is smart, given it makes for a nice truthy/falsy test – even if the API is still goofy, it reflects the complicated situation of mixing containers, support and formats. In SoundManager 2, I look for a “probably” response as an indicator of support for a given format; I also specify codecs in the test and try a few variants to coax a best-case response out of the given browser. Despite best efforts, some browsers won’t say “probably” at this time.

Of course, if developers simply drop <audio> elements and use multiple <source> tags, most of this becomes moot as the browser handles it all – but the dynamic, JavaScript application land is what I’m most interested in, and is where things get pretty funky. It’ll be interesting to see how things evolve.

Patrick: You are correct that HTML does not mandate a standard image format, but it was a different (i.e., research-oriented) environment back when browsers were implementing image support vs. today’s business/commercial web world, of course.

GIFs still work in browsers despite some copyright assertions, and we still have the IE 6 PNG problem, but that browser is finally – wait for it – fading, itself. ;) (zing! / groan / boo, hiss, etc.)

I forgot to mention, I’m on the twitters over at @schill and try to share interesting and nifty things I find about JS, audio, CSS and so on.

Patrick H. Lauke

“With img, you typically don’t have to worry about format support – it just works – and that’s part of what makes a standard wonderful. JPEG, PNG, BMP, GIF, even TIFF images all render just fine”

note though that HTML never actually defined any formats that browsers should support. which image formats browsers actually support can also still vary (thinking PNG24 and IE for instance). and who can forget the patent war around GIF?

yes, NOW the situation is fairly stable, but it’s not always been this way. same thing with audio/video formats/codecs

Bart Lewis

Love the title of this post! While I understand we can’t really expect a boolean response (true/false), the return values of “probably”, “maybe”, and “no” are downright laughable. Truly a glass is half empty API. ;)

Impress us

Be friendly / use Textile