Choosing an audio file for a webpage involves more than selecting an extension from an export menu. You need a version that listeners can open, understand and navigate without unnecessary waiting. You may also need a separate original for editing, archiving or future distribution.
This guide explains the common labels and gives you a practical decision process. It is useful whether you are checking a recording someone sent you or preparing your own podcast, music excerpt or spoken lesson. Start with the audio browser player overview for the listening controls; use this article for the file and delivery choices behind them.
1. Begin with the listening task
Write down what the listener needs to do. A language learner may replay individual phrases many times. A prospective client may listen to a short music sample. A podcast listener may open a long conversation on a mobile connection. Those tasks create different priorities for navigation, sound quality, duration and download size.
Also distinguish the delivery copy from your source material. Keep an untouched original in your normal project storage before experimenting with exports. Give each delivery candidate a useful name so you can connect the listening result to its settings. “Lesson-intro-128k” tells you more during a test than several files named “final.”
A simple decision note is enough: intended audience, approximate length, likely devices and whether the material is mainly speech or music. You can then compare candidates against a real requirement. Avoid declaring one format best for every page when the actual listening tasks differ so much.
2. Read the format label in two parts
A codec describes the encoding of the audio. A container organizes media data and related information in a file. The extension is a useful clue, but it does not always identify every relevant encoding detail. For example, an M4A file commonly contains AAC audio, but that filename alone is not a complete compatibility report.
The MDN web audio codec guide explains common codecs and their relationships with containers. Its broader lesson for a publishing workflow is straightforward: consider the actual format combination and the environment in which it will play.
If a file does not open, inspect its export information where available. Do not change the extension and assume the audio has been converted. If you need another format, create a new export from the original using an appropriate tool, then test that new file. Keep the rejected candidate until you understand what changed, especially when several people are reviewing the same recording.
3. Evaluate MP3 and AAC as delivery candidates
MP3 and AAC use lossy compression, which reduces data by discarding some information. Both are common choices for distributed audio, but the codec name does not tell you whether a particular export sounds good. Encoding settings and the material you started with still matter.
For a spoken episode, compare a quiet passage, a lively exchange and any music introduction. For a music sample, include the densest section as well as an exposed voice or instrument. A candidate that seems fine during the first five seconds may deserve a different judgment elsewhere.
If you plan to publish through a podcast platform, check that platform's current delivery requirements before settling on your export. A file that works in a browser is not automatically the right submission for every distributor. The podcast browser player guide helps separate the episode page, feed and listening interface. Keep that separation in mind when someone reports that a show is visible but one episode will not start.
4. Place Opus, FLAC and WAV in the workflow
Opus is a lossy codec designed to handle speech and music. FLAC provides lossless compression. WAV is a container often used for uncompressed PCM audio. These labels describe different technical choices, so they should not be ranked simply from “small” to “professional.”
Use the intended handoff to guide your comparison. A compressed delivery copy may suit a short web preview. A lossless or uncompressed source may suit continued editing or an archive. If a collaborator asks for a particular format, clarify whether they want an editable original, a review copy or a file ready to publish.
A useful project can therefore contain more than one version without becoming confusing. Keep one clearly named source, one approved delivery copy and a short record of its export settings. Remove obsolete review versions from the public page. Listeners should not have to guess among several near-identical filenames to find the recording they were promised.
5. Estimate file size before uploading
For a constant-bitrate example, multiply the bitrate in bits per second by the duration in seconds, then divide by eight to convert bits into bytes. A one-hour recording at 128 kilobits per second works out to roughly 57.6 megabytes using decimal units. That estimate describes the audio data and excludes additional overhead.
Here are three illustrative calculations for the same one-hour duration:
- 64 kilobits per second: approximately 28.8 MB.
- 128 kilobits per second: approximately 57.6 MB.
- 192 kilobits per second: approximately 86.4 MB.
These are arithmetic examples, not recommended quality settings. Variable-bitrate files do not maintain one fixed rate throughout the recording, so inspect the completed export for its actual size. File size also cannot tell you whether voices are intelligible or music has distracting artifacts.
Use the estimate to ask better questions. Would a shorter preview meet the purpose? Is the extra size buying a noticeable improvement for this material? Would a transcript help someone who cannot listen right now? The answers may improve the page more than an automatic choice of the largest export.
6. Compare sound without changing everything else
Choose a short reference passage and listen to each candidate through the same output at a comparable level. Keep the browser, headphones and room conditions steady. If one version is much louder, your impression may reflect the level difference rather than the format choice you meant to evaluate.
Listen for problems you can describe. Are the ends of words clear? Does a quiet phrase remain understandable? Are there clicks at edits or an unexpected silence before the ending? For music, note any specific moment that sounds different and return to the original before deciding whether the export caused it.
Record your observations in ordinary language. “The final consonants blur at 02:10” is a more useful review note than “the codec sounds bad.” If all versions share the issue, investigate the source recording. If only one candidate exhibits it, revisit that export. Our podcast listening workflow includes a simple way to keep timestamps and review notes connected to the correct episode.
7. Test the published page from beginning to end
After uploading, open the actual page a listener will receive. Test the start, a middle section and the ending. Pause and resume. Move to a later point without first listening through the whole file. Check whether the visible title and duration identify the intended version.
Repeat the essential actions on the device types you intend to support. Avoid treating a successful local-file preview as the final test of the hosted page. The server response, the player and the browser environment are part of the delivered experience. If a problem appears, record which action failed and whether it affects another recording on the same site.
For publishers, keep the file's content type and link path consistent with the actual export. Provide descriptive text around the player so someone can understand what the recording contains before starting it. Where you offer a download, label it clearly with its format and approximate size. Our web browser player guide covers the surrounding page experience and the choices that make media easier to use.
8. Keep the choice explainable
A good browser audio decision can be described in a sentence: this delivery copy works on the intended devices, preserves the detail listeners need and has a sensible size for the session. That is a stronger standard than choosing a format because its name appears more advanced.
Preserve the original, compare a small number of exports and test the completed page. Keep the result and the settings together so future updates do not require starting over. When a playback report arrives, you will have a known file, a repeatable listening check and a clearer starting point for finding the cause.
Have a question or a correction? Contact Browser Player Lab.
