Audio cannot fit in a QR code, so this is a hosting decision
A QR code holds a maximum of about 2,953 bytes. One second of audio at a modest 128 kbps is 16,000 bytes. So an MP3 code is a link to a hosted file, and everything that determines whether it works well happens on the hosting side.
The interesting question is not how to make the code. It is what the listener's phone does when the link opens, and that varies more than most people expect.
Direct file link or streaming page?
A direct link to an .mp3 file opens the browser's bare audio player — a thin strip with a play button and a scrub bar, no artwork, no title, no context. On iOS Safari this is functional; on some Android browsers the file downloads instead of playing.
It is also unforgiving on data: the browser may buffer the whole file before playing, so a 40 MB recording means a long wait with nothing happening.
A streaming page — SoundCloud, Spotify, Bandcamp, a podcast host, or a page on your own site with an <audio> element — gives you progressive playback, a real interface, artwork, and a title. It is slower by one page load and better in every other respect.
For anything a stranger will scan in public, use a page. Direct file links are right when the listener is expected to download and keep the file.
Compression, and the size you should be aiming for
Bitrate choice is where most of the practical gain is:
| Bitrate | Size per minute | Suits |
|---|---|---|
| 64 kbps mono | 0.5 MB | Speech, audio guides, voice notes |
| 96 kbps | 0.7 MB | Speech with some ambience |
| 128 kbps | 1 MB | General listening, adequate for music on phone speakers |
| 192 kbps | 1.4 MB | Music where quality matters |
| 320 kbps | 2.4 MB | Rarely justified for mobile playback |
Spoken word at 320 kbps stereo is wasted bandwidth. A ten-minute museum audio guide is 24 MB at that setting and 5 MB at 64 kbps mono, and no visitor listening through a phone speaker or cheap earbuds will hear the difference. Mono alone halves the file for any single-voice recording.
Normalise the loudness too. A recording that plays quietly on a phone speaker in a gallery with background noise is effectively inaudible, and the listener will assume the code is broken rather than turning up the volume.
The autoplay rules that will defeat you
Every mobile browser blocks audio that starts without user interaction. This is a hard rule, not a setting:
- iOS Safari blocks autoplay of any audio with sound. A page that tries to play on load simply does not.
- Chrome on Android applies a media engagement heuristic; for a first-time visitor, it blocks.
The consequence: you cannot build a "scan and it starts playing" experience. The listener will always have to tap play. Design for that — a large, obvious play button above the fold, not a small control buried under a paragraph of introduction.
This is the single most common disappointment with audio QR codes. People imagine a scan-and-listen flow and build a page that silently does nothing.
Formats and compatibility
MP3 is the safe default — it plays on every browser, every OS, and every device made in the last twenty years. It is the right choice for a QR code precisely because you have no idea what will be pointed at it.
AAC (in an .m4a container) gives better quality at the same bitrate and is well supported on modern devices, but has more edge cases on older Android. Opus is more efficient again and is not supported by Safari in all contexts. WAV is uncompressed and roughly ten times the size — never serve it over a QR code.
If you are serving from your own page, an <audio> element with an MP3 source covers effectively everyone.
Hosting choices
Your own server gives you control, a stable URL, and the ability to replace the file without reprinting. You need correct MIME types (audio/mpeg) and, ideally, support for HTTP range requests so the browser can start playing before the file finishes downloading. Most standard web servers handle this by default; some minimal static hosts do not, and the symptom is audio that will not scrub or takes forever to start.
Cloud storage links tend to interpose a preview page or force a download, and long share URLs make the code denser. Test while signed out — a link that works for you may prompt everyone else to request access.
Podcast hosts and music platforms handle streaming, bandwidth and analytics properly, and give you a page with artwork and a title. They also put their own branding and app prompts in front of your audio.
Where audio codes genuinely work
Museum and gallery labels. A code beside an exhibit leading to a two-minute commentary is the strongest use case there is — cheap to produce, easy to update, no hardware to lend out or sanitise, and it works in the visitor's own language if you provide multiple codes.
Heritage and nature trails. Waypoint markers with a short recording about what you are looking at. Warn visitors to download before setting off if signal is poor.
Language learning material. Pronunciation of a phrase printed on the page.
Accessibility. An audio version of printed text for visually impaired readers, or for anyone who finds reading difficult. This is a genuine equity gain and costs very little.
Product packaging. Setup instructions or a welcome message, particularly for products aimed at people who do not want to read a manual.
Music promotion. Posters, flyers and merchandise linking to a track — though a streaming platform link almost always beats a raw file here.
Greetings cards and gifts. A recorded message from a person, which is a small thing that lands surprisingly well.
Practical checklist
- Export at a bitrate appropriate to the content — mono for speech, and do not exceed 128 kbps without a reason.
- Normalise loudness so it is audible on a phone speaker in a noisy room.
- Host it where you control the URL, so the recording can be replaced later.
- Test the link on iOS Safari and Android Chrome, signed out, on mobile data rather than office WiFi.
- Put a clear play button on the landing page and do not rely on autoplay.
- Print a line of text next to the code saying what it is and roughly how long — "Curator's note, 2 min" earns far more scans than a bare code.
- If it is a trail or a signal-poor venue, tell people to download in advance.
Frequently asked questions
Can a QR code contain the audio file itself?
No. A QR code holds at most about 2,953 bytes — under a fifth of a second of audio. Every audio QR code is a link to a hosted file.
Will the audio play automatically when scanned?
No. Every mobile browser blocks audio that starts without a user gesture, and there is no way around it. Design the landing page with a large, obvious play button rather than expecting playback to begin on its own.
What bitrate should I use?
64 kbps mono for speech, 128 kbps for general music listening. Spoken word at 320 kbps stereo produces a file five times larger with no audible benefit on a phone speaker or earbuds.
Should I link straight to the MP3 file or to a page?
A page, for anything the public will scan. A direct file link gives a bare browser player with no title or artwork, and downloads rather than plays on some Android browsers. Direct links suit cases where the listener is meant to keep the file.
Does it work without internet?
No — the file has to be fetched. For trails and venues with poor signal, tell visitors to download the audio before they set off, or provide the whole set as a single download at the entrance.
Can I update the recording later?
Yes, if the code points at a stable URL you control and you replace the file behind it. Encoding a versioned filename removes that option.
Which audio format is safest?
MP3. It plays everywhere without exception, which matters when you have no control over what device will be pointed at the code. AAC and Opus are more efficient but have more edge cases; WAV is roughly ten times the size and should never be served this way.