How to add audio to an HTML email

Adding a play button to an email sounds simple. Add an <audio> element, point it at an MP3, and ship it.

Then you open the campaign in Gmail or Outlook and discover the real problem: email clients do not agree on whether the player should render, whether it should play, or whether its fallback content should survive sanitization.

Audio in email can still work well. The safe approach is progressive enhancement. Recipients in supporting clients get a native player. Everyone else gets a clear link to a web version where the audio can play normally.

This guide explains the production pattern we use, why each part exists, and what to test before sending.

The short answer

Use native HTML audio as an enhancement, never as the only way to access the content.

<audio controls preload="none">
  <source
    src="https://example.com/audio/product-update.mp3"
    type="audio/mpeg"
  />
  <a href="https://example.com/product-update">
    Listen in the web version
  </a>
</audio>

The text and link inside <audio> are fallback content. A client that does not support the element may show that content instead of the player.

That small example is a useful starting point, but it is not enough for a production campaign. Some clients remove the element and everything inside it. Others display a player that cannot load the audio because of security restrictions. That is why the complete pattern also includes a separate fallback link.

Where audio works

Support is concentrated in clients that use Apple's rendering engine. Apple Mail on macOS, iPhone, and iPad is the most important example. Some other WebKit based apps can also render native audio controls.

The major limitations are:

Client family	Expected result
Apple Mail on macOS and iOS	Native player usually works
Gmail	Do not rely on a playable native player
Outlook for Windows	Native audio is not reliable
Outlook on the web	The element can appear, but playback can be blocked by Content Security Policy
Yahoo Mail and AOL	Do not rely on native playback
Fastmail and some privacy focused clients	The element and its contents may be removed

The mail application matters more than the email address. A Gmail address opened in Apple Mail can behave like Apple Mail. The same address opened in Gmail can behave differently.

Support data also changes as clients update their rendering engines and sanitizers. Check the current <audio> support matrix on Can I email before using the pattern in a major send.

Why ordinary embedded players do not work

Podcast platforms and audio services often provide an embed based on JavaScript or an <iframe>. Those embeds are designed for web pages, not inboxes.

Most email clients remove JavaScript. Many also remove iframes and unfamiliar interactive markup. The native <audio> element is the only realistic in-email player, because it does not require a script to display its controls.

This also means that the controls attribute is essential. There is no dependable JavaScript button available to start or stop playback.

A production ready pattern

The following example starts with the fallback visible and the player hidden. Supporting WebKit clients switch those states. Outlook on the web is then forced back to the fallback because it can expose a player that cannot play.

Replace the URLs, labels, and your platform's web version token before sending.

<style type="text/css">
  .audio-player {
    display: none;
  }

  .audio-fallback {
    display: inline-block;
  }

  @media screen and (-webkit-min-device-pixel-ratio: 0) {
    .audio-player {
      display: block !important;
    }

    .audio-fallback {
      display: none !important;
    }
  }

  /* Outlook on the web can expose a player that cannot play. */
  #MessageViewBody .audio-player {
    display: none !important;
  }

  #MessageViewBody .audio-fallback {
    display: inline-block !important;
  }

  /* Outlook webmail commonly prefixes classes with x_. */
  [class~="x_audio-player"] {
    display: none !important;
  }

  [class~="x_audio-fallback"] {
    display: inline-block !important;
  }

  /* Gmail targeting restores the safe default. */
  u ~ div .audio-player {
    display: none !important;
  }

  u ~ div .audio-fallback {
    display: inline-block !important;
  }
</style>

<div class="audio-player">
  <audio controls preload="none">
    <source
      src="https://example.com/audio/product-update.mp3"
      type="audio/mpeg"
    />
    <a href="https://example.com/product-update">
      Listen in the web version
    </a>
  </audio>
</div>

<a
  class="audio-fallback"
  href="https://example.com/product-update"
  style="font-family: Arial, sans-serif;
         font-size: 15px;
         line-height: 24px;
         font-weight: bold;
         color: #3b82f6;
         text-decoration: none;"
>
  Listen in the web version &#9658;
</a>

<!--[if mso]>
  <div style="margin-top: 8px;">
    <a
      href="https://example.com/product-update"
      style="font-family: Arial, sans-serif;
             font-size: 15px;
             line-height: 24px;
             font-weight: bold;
             color: #3b82f6;"
    >
      Listen in the web version
    </a>
  </div>
<![endif]-->

This pattern is intentionally defensive. Email CSS targeting techniques depend on client specific behavior, so they should be treated as tested compatibility rules rather than web standards.

What each part does

The native player

<audio controls preload="none">

controls asks the client to show its native play, pause, timeline, and volume interface.

preload="none" asks the client not to fetch the file until the recipient interacts. It reduces unnecessary transfer and helps avoid counting a preload as a listen. A client or security scanner can still ignore the hint, so it is not a measurement guarantee.

Avoid autoplay. It is frequently blocked, creates an accessibility problem, and can surprise recipients in public or quiet environments.

The source element

<source
  src="https://example.com/audio/product-update.mp3"
  type="audio/mpeg"
/>

The source must use HTTPS and be reachable without authentication. Serve the correct MIME type and support byte range requests, because media players often request only part of a file at a time.

MP3 is the practical default for broad playback support. AAC in an M4A container is also a good option for Apple focused audiences. If file size permits, you can provide more than one source:

<audio controls preload="none">
  <source src="https://example.com/audio/update.m4a" type="audio/mp4" />
  <source src="https://example.com/audio/update.mp3" type="audio/mpeg" />
  <a href="https://example.com/product-update">Listen online</a>
</audio>

The client chooses the first format it can play.

Fallback content inside audio

HTML allows content between the opening and closing audio tags. Browsers normally show it only when they cannot render the element.

In email, sanitization complicates that rule. One client may preserve the link. Another may remove the entire audio block, including the fallback. The inner link is useful, but it should not be your only fallback.

A separate fallback link

The separate .audio-fallback link survives even when a client removes <audio>. It is the most important safety layer.

Link to a web page, not only to the raw audio file. A web version gives you control over the player, transcript, context, analytics, download options, and any next action.

If your sending platform provides a hosted web version token, you can use that URL. In Better Email, for example, the exported code can contain the web version token required by the destination platform.

Outlook conditional comments

The final link is wrapped in an MSO conditional comment:

<!--[if mso]>
  Outlook-only fallback content
<![endif]-->

Classic Outlook on Windows uses Microsoft Word to render HTML email. It understands this syntax while other clients treat it as a comment. The extra link protects recipients when normal display rules are changed or ignored by Word.

Read our guide to MSO attributes and conditional comments for a deeper explanation.

Outlook on the web targeting

Outlook on the web is not the same renderer as classic Outlook for Windows. It can match WebKit oriented CSS while still blocking the remote media request through its Content Security Policy.

#MessageViewBody and the x_ prefixed class selectors target common Outlook webmail transformations. Their job is to hide the unusable player and restore the web link.

These selectors are implementation details, not formal APIs. Test them regularly.

Accessibility requirements

Audio should never make the message harder to use.

1. Do not autoplay.
2. Add a visible text link even if the player works.
3. Provide a transcript in the email or on the linked page.
4. Give the link a specific label such as "Listen to the July product update" instead of "Click here".
5. Do not communicate essential information only through audio.
6. Keep the link large enough to tap comfortably on a phone.

A transcript also helps recipients who are in a noisy environment, do not have headphones, use assistive technology, or prefer scanning text.

Hosting and tracking considerations

The audio request does not behave exactly like an ordinary tracked link click.

A player may send several byte range requests during one listen. Some clients may inspect the source before playback. Privacy systems and security scanners can also create requests that are not human listens.

For useful measurement:

1. Keep the web fallback as a normal tracked link.
2. Treat audio file requests as directional engagement, not a perfect count of listeners.
3. Use a unique audio URL for each campaign if you need campaign level reporting.
4. Inspect range requests before converting raw server hits into play counts.
5. Do not use preload="auto" if a download would inflate your reporting or podcast statistics.

The audio server should return a valid Content-Type, a sensible cache policy, and support partial content responses. Test the URL outside the email before testing the campaign.

A simpler pattern for less critical audio

If audio is optional and the email still makes complete sense without it, you can use a smaller pattern:

<audio controls preload="none">
  <source
    src="https://example.com/audio/update.mp3"
    type="audio/mpeg"
  />
  <a href="https://example.com/product-update">
    Listen to the product update online
  </a>
</audio>

<p>
  <a href="https://example.com/product-update">
    Prefer the web player? Listen here.
  </a>
</p>

The visible paragraph is deliberately redundant. In email development, reliable access is more valuable than avoiding one repeated link.

Testing checklist

Do not approve an audio campaign from a browser preview alone. A browser is usually more capable than an inbox.

Before sending, verify:

1. Apple Mail on macOS shows the player and plays the file.
2. Apple Mail on iPhone shows usable controls and continues to behave after the screen locks or the message is left.
3. Gmail on desktop and mobile shows a working fallback link.
4. Classic Outlook for Windows shows a fallback link and no broken player.
5. Outlook on the web shows the fallback link instead of an unusable control.
6. The web version opens without authentication and plays on mobile.
7. The MP3 or M4A endpoint uses HTTPS, the right MIME type, and byte range support.
8. A transcript is available.
9. The email still communicates its main point with images blocked and audio unavailable.
10. The final exported HTML still contains the audio source and the correct web version token.

Run this matrix again after changing your sending platform, export integration, or email template. Any of those systems may sanitize or rewrite the markup.

The principle to remember

Audio in email is not an all or nothing feature.

Build the campaign so the native player is a bonus. The core message, transcript, and web link must work everywhere. With that hierarchy in place, supporting clients get a richer experience while every other recipient still gets a dependable way to listen.

Sources and further reading

• Can I email: HTML audio support
• Podnews: the audio tag in email
• Better Email: MSO attributes in Outlook emails