The src Attribute & source Element

Technical Deep Dive & Specifications

Direct src Attribute vs. Child <source> Elements

There are two primary syntactic patterns for declaring an audio resource:

Pattern A: Direct src Attribute on <audio>

<audio controls src="media/track.mp3"></audio>

• Use Case: Simple, internal applications where all target clients are guaranteed to support a single codec (e.g., standard MP3).
• Limitation: Zero codec negotiation. If the client’s platform lacks support for that format (e.g., trying to play Ogg Vorbis in older Safari), playback fails completely.

Pattern B: Multi-Candidate <source> Child Cascade

<audio controls>
  <source src="media/track.opus" type="audio/ogg; codecs=opus">
  <source src="media/track.m4a"  type="audio/mp4; codecs=mp4a.40.2">
  <source src="media/track.mp3"  type="audio/mpeg">
  <p>Your browser does not support HTML5 audio.</p>
</audio>

• Use Case: Production-grade web applications delivering cutting-edge, low-bitrate modern codecs to capable devices while maintaining 100% backwards compatibility.

The WHATWG Media Selection Algorithm

When the browser parses an <audio> tag, it executes the standardized Resource Selection Algorithm defined by WHATWG:

[Start Resource Selection]
          |
          v
Does <audio> have a 'src' attribute?
     /        \
   YES         NO
   /             \
[Fetch 'src']     [Iterate through child <source> elements in document order]
                        |
                        v
                  Does <source> have a 'type' attribute?
                       /        \
                     YES         NO
                     /             \
            Can browser decode?    [Send HEAD/GET request to inspect Content-Type]
                 /        \               |
               YES         NO             v
               /             \     Can browser decode?
  [Select this source]  [Skip to next]    /        \
                                       YES         NO
                                       /             \
                         [Select this source]   [Skip to next]

Step-by-Step Specification Rules:

1. The src Override: If the parent <audio> element has a src attribute, the browser exclusively uses that URL. It completely ignores all nested <source> tags.
2. Sequential Traversal: If <audio> lacks a src attribute, the engine inspects <source> children in top-to-bottom order.
3. MIME Type Pre-flight Filtering: If a <source> has a type attribute, the browser performs an internal capability check against its decoder registry. If unsupported, the browser immediately skips to the next <source> without making any network HTTP request.
4. Network Fallback Check: If a <source> lacks a type attribute, the browser is forced to send an HTTP GET/HEAD request to read the server's Content-Type header, wasting network latency and round trips.

MIME Types and RFC 6381 Codec Strings

A MIME type tells the browser the container format. Adding the optional codecs parameter (standardized in RFC 6381) specifies the exact internal audio compression algorithm:

Probing Support with HTMLMediaElement.canPlayType()

JavaScript can query the browser’s media engine directly to test format compatibility before attaching audio sources:

const audio = document.createElement('audio');

const opusSupport = audio.canPlayType('audio/ogg; codecs="opus"');
const aacSupport  = audio.canPlayType('audio/mp4; codecs="mp4a.40.2"');
const mp3Support  = audio.canPlayType('audio/mpeg');

console.log('Opus:', opusSupport); // Returns: "probably", "maybe", or ""
console.log('AAC:', aacSupport);   // Returns: "probably", "maybe", or ""
console.log('MP3:', mp3Support);   // Returns: "probably", "maybe", or ""

Why Does canPlayType() Return "probably", "maybe", or ""?

The WHATWG specification explicitly designed canPlayType() to never return a boolean true/false.

• "" (Empty String): The browser definitely cannot play this format (e.g., unsupported container).
• "maybe": The browser recognizes the container (e.g., audio/mp4), but cannot confirm playback capability until it parses the compressed bitstream packets.
• "probably": The browser recognizes both the container AND the specific codec parameter (e.g., audio/mp4; codecs="mp4a.40.2") and possesses an active decoding pipeline for it.

HTTP 206 Partial Content & Byte-Range Streaming

Audio files can range from a few kilobytes to hundreds of megabytes (e.g., 2-hour podcast episodes). To allow instant playback and timeline seeking without downloading the entire file into client RAM, the server must support HTTP 206 Partial Content (RFC 7233).

+-----------------------------------------------------------------------------------------+
|                    HTTP 206 BYTE-RANGE STREAMING NEGOTIATION                            |
+-----------------------------------------------------------------------------------------+
|  Client (Browser)                                         Origin Server / CDN           |
|         |                                                         |                     |
|         | ── 1. GET /podcast.mp3 ───────────────────────────────> |                     |
|         |    (Initial request or Range: bytes=0-)                 |                     |
|         |                                                         |                     |
|         | <── 2. HTTP/1.1 206 Partial Content ─────────────────── |                     |
|         |    Accept-Ranges: bytes                                 |                     |
|         |    Content-Range: bytes 0-32767/45120000                |                     |
|         |    Content-Length: 32768                                |                     |
|         |    [Receives audio header + duration metadata]          |                     |
|         |                                                         |                     |
|         |      [User seeks forward to 45:00 mark in timeline]     |                     |
|         |                                                         |                     |
|         | ── 3. GET /podcast.mp3 ───────────────────────────────> |                     |
|         |    Range: bytes=15000000-16000000                       |                     |
|         |                                                         |                     |
|         | <── 4. HTTP/1.1 206 Partial Content ─────────────────── |                     |
|         |    Content-Range: bytes 15000000-16000000/45120000      |                     |
|         |    [Decodes and plays audio immediately at 45:00]       |                     |
+-----------------------------------------------------------------------------------------+

Crucial HTTP Headers for Web Audio Streaming:

1. Accept-Ranges: bytes: Informs the browser that the server accepts arbitrary byte-offset slices.
2. Range: bytes=START-END: Sent by the browser to request a specific byte window.
3. Content-Range: bytes START-END/TOTAL: Sent by the server confirming the exact byte slice returned and the total file size.

What Happens If the Server Only Returns HTTP 200 OK (No Byte Ranges)? If a web server does not support byte ranges, scrubbing/seeking forward along the timeline is blocked until the entire audio file is sequentially downloaded. On mobile networks, this causes massive data consumption and freezes playback.

💻 Interactive Code Playground

Starter Code

Line-by-Line Code Breakdown

• Line 41 (<audio id="player" controls preload="metadata">): Note that the <audio> tag deliberately omits the src attribute, allowing child <source> elements to be evaluated.
• Lines 43–44 (<source src="...webm" type='audio/webm; codecs="opus"'>): First candidate. If Chrome or Firefox parses this, it verifies Opus decoding support via the type attribute and downloads the WebM asset.
• Lines 47–48 (<source src="...m4a" type='audio/mp4; codecs="mp4a.40.2"'>): Second candidate. In Apple Safari environments, AAC in MP4 is prioritized and chosen.
• Lines 51–52 (<source src="...mp3" type="audio/mpeg">): Third candidate. Universal fallback guaranteed to decode on virtually every platform in existence.
• Line 66 (player.currentSrc): Reads the read-only DOM property HTMLMediaElement.currentSrc, which returns the absolute URL of the specific candidate chosen by the media selection algorithm.

Expected Browser Render Output

+-------------------------------------------------------------+
| High-Fidelity Audio Streamer                                |
| The browser negotiates the highest efficiency codec...      |
|                                                             |
| [ > ] [=============================] 0:00 / 0:02 [ 🔊 ] [: ] |
|                                                             |
| Active Source URL: .../t-rex-roar.webm                      |
| Duration: 2.15 seconds                                      |
| Network State: 1 (NETWORK_LOADING / IDLE)                   |
+-------------------------------------------------------------+