Free tool · nothing uploaded

Audio metadata viewer, in plain English.

A free audio metadata viewer that reads your file on your own device. Drop one in and you get a paragraph anyone can understand: what it is, when it says it was made, what software has written it, and whether it is carrying anything you would rather it did not. No upload, no sign-up, no jargon required.

Free & unlimitedNothing uploadedNo sign-upWorks offlinePrintable reportNo verdicts

Drop an audio file here

You get a plain-English answer in about a second. There are no settings to choose — the file says what it is, and this page reads it on your own device.

M4A · MP3 · WAV · MOV · MP4 · Opus · Ogg · FLAC · WebM · AMR · 3GP — and anything else, which still gets what can be read from it. You can also paste a file.

Your privacy — live proof, not a promise

Files uploaded: 0 bytes
Read from your disk: 0 bytes
Where it was read: Nothing read yet
Kept afterwards: Nothing — closing this tab discards it all

This tool downloads nothing either

The transcriber on this site fetches a speech model once, and the converter fetches a conversion engine once. This page fetches neither. Reading a file’s labels is arithmetic on bytes that are already on your device, so after this page has loaded there is no second request of any kind — which is why it works with Wi-Fi switched off.

Check it yourself: open your browser’s developer tools, clear the Network panel, then drop a file in. Nothing appears carrying your audio, because this page has no upload feature, no API route and no server behind it. Then turn off Wi-Fi and inspect a second file — it behaves identically.

Scope note, so this stays exact: the claim is about your file — it never leaves this device. The site around it is not claim-free. It loads Vercel Analytics for aggregate page traffic, plus Google Analytics and Ads tags if you accept the consent prompt. Those measure page visits and store-link clicks. They never receive your recording or anything read out of it, because nothing does. Full privacy policy.

What this tool can and can’t tell you

Everything else in this space overclaims, usually with a badge and a percentage. This is the honest version, and the second list is longer than the first on purpose.

What it can tell you

What the file actually is, from its bytes rather than its name — which explains most 'this will not open' problems in one line.
How long it is, both as the file declares it and, where the format allows, as measured from the audio itself.
What date and device the file records, if any, and how much weight that date can carry.
Which software has named itself inside the file, and what that software is commonly used for.
Whether the file is carrying location data you may not want to send to anyone.
Whether the file is complete, or stops part-way through its own structure.
How the audio is stored — codec, sample rate, channels, bitrate — and what those settings are typical of.
For Broadcast WAV files, the full coding history: an ordered record of what processed the file.

What it cannot tell you

Whether a recording is genuine. There is no field in any audio format that establishes this, and any tool claiming otherwise is guessing.
Whether a recording has been edited. Editing software leaves the same traces as software that only saved the file untouched — often none at all.
Who recorded something, or who edited it. Names in a file identify programs, not people.
Whether a date is true. Every timestamp in every audio file is a value written by software, into a file anyone can modify with a hex editor.
What was said, or what was removed. This tool never listens to your audio for content, and metadata cannot describe content.
Whether a gap in a recording is a pause or a join. The waveform looks the same either way, which is why this tool lists moments to listen to and stops there.
Whether a file is the original. A perfect copy is identical to its source in every field this tool reads.
Anything at all about the audio in a file whose metadata was stripped — and stripping metadata is what most sharing, converting and exporting does by default.

This is a metadata reader, not forensic authentication

It reads the labels a file carries about itself and explains what they usually mean. It cannot prove a recording is genuine, and it cannot prove one was altered — no tool that reads metadata can, because every field it reads is ordinary data that any program can write. Nothing here is a verdict. If a recording matters to a legal case, a disciplinary process or a formal complaint, it needs a qualified forensic audio examiner, who works from the audio signal itself and can testify to their method.

On the legal side, the recording consent checker and the recording laws by jurisdiction cover which rules may apply where you are. Both are general information, not legal advice, and neither is a substitute for asking a lawyer about your own situation.

How an audio metadata viewer works without uploading anything

Every audio format begins with a description of itself — how the sound is stored, how long it is, and often when it was made and by what. Reading that is arithmetic on bytes, and your file is already on your device, so there is nothing to send anywhere.

Drop a file in

Or press the button and pick one. Nothing is sent anywhere — your browser opens the file from your own disk, the same way a music player does.

The labels get read, here

Every audio format keeps a set of labels about itself: when it was made, what wrote it, how the sound is stored. Reading them is just reading bytes, so it happens in this tab in a fraction of a second.

You get sentences, not a table

The first thing you see is a paragraph in plain English, then a handful of things worth knowing. Every technical detail is still there, folded away, for whoever needs it.

Take it with you

Download a report you can print or save as a PDF, or copy a plain-text summary into an email or a case note. Both include the caveats, because they belong with the findings.

Every parser is hand-written

No library, no conversion engine, no download. This page reads MP4-family files (MP4, M4A, M4B, MOV, 3GP) box by box; WAV chunk by chunk, including the Broadcast WAV block professional recorders write; MP3 frame by frame, along with its ID3 tags and its encoder’s own signature; Ogg by walking its pages to the last one; FLAC’s stream header and comments; Matroska and WebM through their element tree; and AMR frame by frame. Anything it does not recognise still gets a report — the size, the opening bytes, and what those identify the format as.

Glossary: what every audio metadata field can and cannot show

One entry per field, each with the part everyone else leaves out. Every heading is a permanent link, so a specific field can be cited directly.

bext chunk

Broadcast WAV extension, BWF

An optional block inside a WAV file, defined by the European Broadcasting Union, holding an originator name, an origination date and time, a sample-accurate time reference, a unique material identifier and a coding history. Field recorders, broadcast systems and professional editing software write it; phone recorders and consumer apps essentially never do.

What it can show: Show what equipment or software declared itself as the originator, what date and time that equipment believed it was, and — through the coding history — the sequence of processes the file passed through.
What it cannot show: Prove any of it. Every field is ordinary text and numbers written by software into a file that anyone can edit with a hex editor. Its value is that consumer tools do not write it and generally do not preserve it, not that it is protected in any way.

Coding history

CodingHistory, part of the bext chunk

A free-text field inside a Broadcast WAV file to which each piece of equipment or software appends one line as it processes the file, recording the coding type, sample rate, bit depth, mode and its own name.

What it can show: Give an ordered account of the processing steps a file went through, often naming specific hardware and settings. It is the richest provenance field in ordinary use.
What it cannot show: Be relied on as complete. Software that does not know about the field simply drops it, and nothing forces a program to append a line. A short history does not mean few steps — it may mean one step that discarded the rest.

UMID

Unique Material Identifier, SMPTE 330M

A 32- or 64-byte identifier written into a Broadcast WAV file, intended to be unique to one piece of recorded material. Basic UMIDs identify the material; extended ones can also carry a date, a time and a location.

What it can show: Link a file to other files claiming the same material, and sometimes carry a recording date independent of the other date fields.
What it cannot show: Authenticate anything. It is generated by the recorder and copied along with the file, like any other field.

mvhd atom

Movie header, in MP4, M4A and MOV files

The header of an MP4-family file, holding the file's creation and modification times, its timescale and its duration. The times are counted in seconds from 1 January 1904 — a QuickTime convention that predates the Unix epoch.

What it can show: Give a creation time and a modification time for the container, and a duration the file itself declares.
What it cannot show: Tell you the time zone. The specification says the value is UTC; Apple, Android and most cameras write local time into it instead. There is no field recording which was meant, so a time read from mvhd is a clock reading with no zone attached. It also cannot survive most re-saving: software that rewrites the container writes fresh times.

com.apple.quicktime.creationdate

Apple's creation date key

A metadata key Apple devices write alongside the ordinary header times, holding a full ISO 8601 timestamp including the UTC offset the device was set to.

What it can show: Give a creation time that does include a time zone, which the ordinary header time does not. When present, it is the better of the two.
What it cannot show: Establish that the device's clock was correct, or that the value was written by the device rather than added later. It is a tag like any other.

mdhd atom

Media header

The per-track header inside an MP4-family file, holding the timescale and duration of that specific track along with a language code.

What it can show: Give the duration of the audio track itself, which can differ from the whole file's declared duration when a file carries more than one track.
What it cannot show: Say anything about the content of the audio, or about how the file was produced.

ftyp brand

File type box, major brand

The first box in an MP4-family file, declaring a four-character 'brand' — M4A, isom, qt, 3gp — and a list of other brands the file claims compatibility with.

What it can show: Identify what kind of MP4-family file this is, independently of its name. An iPhone voice memo is branded M4A whatever it has been renamed to.
What it cannot show: Say which program wrote the file. Many programs write the same brands.

stsd atom

Sample description

The box inside an MP4-family file that names the codec of a track and holds its configuration: sample rate, channel count and, for AAC, an embedded decoder configuration.

What it can show: Say exactly which codec and settings the audio uses.
What it cannot show: Say what the audio originally was before it was encoded this way.

esds atom

Elementary stream descriptor

A structure inside an MP4 sample description carrying the decoder configuration for AAC and some other codecs, including declared average and peak bitrates.

What it can show: Give the bitrate the encoder declared it was targeting, and the AAC profile in use.
What it cannot show: Be assumed accurate about the actual data rate. The declared value is written once and is not recomputed if the file is later modified.

LAME tag

The encoder block after a Xing header

A block written into the first frame of an MP3 by the LAME encoder and by several programs that imitate it, recording the encoder version string, the bitrate strategy, the lowpass filter frequency, the encoder delay and padding, and the preset used.

What it can show: Identify the encoder and often its exact version and settings — 'LAME3.100' with a -V2 preset is specific information about how the file was produced.
What it cannot show: Identify the program a person was using. LAME sits inside hundreds of applications. Nor can it survive re-encoding: a new encode writes a new tag and the old one is gone.

Xing and Info headers

A block in the first frame of an MP3 holding the total frame count and byte count. The marker reads 'Xing' when the encoder used a variable bitrate and 'Info' when it used a constant one.

What it can show: Give a duration and let a player seek accurately without scanning the whole file, and tell you which bitrate strategy the encoder used.
What it cannot show: Be trusted over the audio itself. It is written once. Trimming an MP3 with a tool that does not rewrite it leaves a header describing a file that no longer exists, which is why this tool counts frames as well as reading it.

Variable and constant bitrate

VBR, CBR, ABR

How many bits per second the encoder spends. A constant bitrate spends the same amount on every second of audio; a variable bitrate spends more on complex passages and less on quiet ones. Average bitrate is a variable rate steered towards a target.

What it can show: Hint at the kind of software involved. Simple phone recorders and voice-note apps overwhelmingly write constant rates; desktop encoders and music software default to variable ones.
What it cannot show: Indicate editing. Both strategies are ordinary configuration choices, available in every encoder, and neither is characteristic of modified audio.

WritingApp and MuxingApp

Matroska and WebM provenance fields

Two fields in a Matroska or WebM file. MuxingApp names the library that assembled the file; WritingApp names the application using that library.

What it can show: Name the software that produced the file, in plain text, more reliably than most fields — ordinary users do not edit these, and they are usually written truthfully by the toolchain.
What it cannot show: Distinguish producing from editing. A file exported unchanged carries the same names as one heavily edited. Nor is the field protected: it is text, and it can be rewritten.

EBML

The structure Matroska and WebM are built on

A binary format shaped like XML: every element is an identifier, a length and a value, with lengths encoded as variable-length integers. Matroska and WebM are both defined on top of it, and the DocType field says which.

What it can show: Tell you whether a file is WebM (the browser and web-video profile) or full Matroska, and let a reader walk the file without knowing the codecs inside.
What it cannot show: Say anything about the audio itself — EBML is only the container's grammar.

OpusHead

The identification header at the start of an Ogg Opus file, giving the channel count, the pre-skip, the sample rate of the audio before encoding, and an output gain.

What it can show: Tell you what the encoder was fed, including the original sample rate, which the decoded output no longer shows — Opus always decodes at 48,000 samples a second regardless.
What it cannot show: Name the software. That comes from the vendor string in the comment header.

Granule position

A running sample count that an Ogg muxer writes onto every page as it goes. The value on the last page is the length of the stream.

What it can show: Give a duration that was measured during writing rather than declared in advance, which makes it unusually trustworthy as a length.
What it cannot show: Survive a file being cut short. A truncated Ogg file simply has an earlier last page, and its duration reads short accordingly.

Vendor string

In Ogg, Opus and FLAC comment blocks

A line written by the encoding library itself at the head of the comment block — 'libopus 1.4', 'reference libFLAC 1.4.3'.

What it can show: Identify the encoding library and version. It is written by the library, not chosen by the user, so it is harder to set casually than an ordinary tag.
What it cannot show: Identify the application. Many programs share the same libraries.

STREAMINFO

FLAC's first metadata block

The mandatory first block of a FLAC file, holding sample rate, channel count, bit depth, total sample count and a checksum of the decoded audio.

What it can show: Give an exact sample count, and therefore an exact duration, plus the audio's full technical shape.
What it cannot show: Say who made the file or when. FLAC keeps those in the separate comment block, if anywhere.

FLAC audio checksum

The MD5 in STREAMINFO

A checksum of the uncompressed audio, computed by the encoder when the file was written and stored in the header. The `flac -t` command-line tool decodes the file and compares.

What it can show: Detect damage. If the stored checksum does not match the audio, something corrupted the file after it was encoded.
What it cannot show: Establish originality. Anyone re-encoding audio produces a fresh, perfectly valid checksum for whatever they encoded. A match means the file is intact, not that the audio is unaltered.

ISO 6709 location tag

©xyz, com.apple.quicktime.location.ISO6709

A compact latitude, longitude and optional altitude written as one string — '+12.9716+077.5946+920.000/' — stored in the metadata of MP4-family files by phones with location access enabled.

What it can show: Show where the device believed it was when the recording was made, usually to a few metres.
What it cannot show: Be assumed absent because you cannot see it. It is invisible in every ordinary player and file manager, which is exactly why people send it to strangers without knowing.

Encoder and software tags

©too, TSSE, ISFT, ENCODER

Free-text fields in which whatever wrote the file names itself. Every container has a version of them.

What it can show: Name a program that handled the file, which is often the single most informative thing available.
What it cannot show: Distinguish saving from editing. Opening a recording and exporting it untouched writes exactly the same tag as an hour of work. They are also free text: anything can write anything into them.

File modification date

The date your file manager shows

A timestamp kept by your operating system's filesystem, not stored inside the file. Your browser exposes it as `File.lastModified`.

What it can show: Tell you when this copy, on this device, was last written.
What it cannot show: Tell you when the recording was made. Copying, downloading, syncing, unzipping, restoring from a backup and moving between devices all rewrite it — routinely, silently, and with no record of the previous value.

Magic bytes

File signature

The first few bytes of a file, which identify its format regardless of what the file is named. WAV files start with 'RIFF', MP4-family files have 'ftyp' at offset four, Ogg files start with 'OggS'.

What it can show: Say what a file actually is, which is often not what its extension claims.
What it cannot show: Say anything about content, origin or history — only about format.

Declared and measured duration

The length a file's header claims, versus the length obtained by counting the audio — MP3 frames, Ogg granule positions, or FLAC's sample count.

What it can show: Show a disagreement between what the container says and what the audio contains.
What it cannot show: Explain the disagreement. Headers that were not updated after a trim, files cut short in transfer, and encoder padding all produce one, and the number alone does not distinguish them.

Sample rate and channels

How many times a second the audio was measured, and how many separate signals were recorded. 8,000 or 16,000 samples a second in one channel is speech; 44,100 or 48,000 in two is music or stereo room capture.

What it can show: Indicate what the recording was configured for, and rule out some claimed sources — a device that only records mono at 16,000 did not produce a 48,000 stereo file.
What it cannot show: Be improved after the fact. Converting a 16,000-sample recording to 48,000 adds numbers, not detail, and a file's rate says nothing about whether it was edited.

Lossy and lossless

Lossy formats — MP3, AAC, Opus, Vorbis, AMR — discard detail permanently to make files small. Lossless formats — WAV, FLAC, ALAC — keep every sample.

What it can show: Tell you what this copy can hold at best.
What it cannot show: Tell you what the audio has already been through. Converting a compressed recording to WAV produces a large lossless file whose contents were compressed earlier; nothing is restored, and the file gives no sign of it.

AMR

Adaptive Multi-Rate, the phone-call codec

A speech codec designed for mobile networks, still written by some phone recorders and voicemail systems. Files hold nothing but a short magic string and 20-millisecond frames.

What it can show: Be recognised, counted and timed exactly.
What it cannot show: Carry a date, a device name, an encoder name or any other metadata. The format has no fields for them. An AMR file with no creation date is not missing anything.

Checking audio file details — your questions, answered

Does this prove a recording is real?+

No, and nothing that reads metadata can. Every field this tool reads — dates, device names, encoder names — is ordinary data written by software into a file that anyone can edit. The tool describes what a file says about itself and what usually puts those labels there. Establishing that a recording is genuine is the work of a qualified forensic audio examiner, who analyses the audio signal itself.

Can you tell if an audio recording has been edited?+

No. This is the question everyone arrives with, and the honest answer is that metadata cannot answer it. Opening a recording in an editor and saving it with nothing changed leaves exactly the same traces as an hour of editing: a new encoder tag, a new modification date, fresh timestamps. Meanwhile, plenty of genuine edits leave no metadata trace at all. What this tool does instead is report what it observes and always state the innocent explanation alongside — because in the great majority of files, the innocent explanation is the true one.

Where does the creation date in an audio file come from?+

It depends on the format. MP4, M4A and MOV files store it in a header called mvhd, counted in seconds from 1904; Apple devices additionally write a fuller timestamp that includes a time zone. Broadcast WAV files store an origination date and time in a bext chunk. MP3 files can carry a date in an ID3 tag. Ogg and FLAC can carry one in a comment field. In every case the value was written by whichever program created the file, from whatever its clock said at the time.

Why does my audio file have no creation date?+

Usually because something re-saved it. Converting, exporting, emailing, uploading to and downloading from cloud storage, and sending through a messaging app all commonly write a fresh file without the original timestamps. Some formats — AMR in particular — have no field for a date at all, so a file in that format never had one. A missing date is a very ordinary thing and is not, by itself, a sign that anything was done to the audio.

Does WhatsApp strip metadata from voice notes?+

In practice, yes — WhatsApp re-encodes audio when it is sent, which produces a new file. The result generally carries the encoding library's own tags rather than anything from the original recorder: no device name, no original creation date, and no location. That happens to every voice note that passes through it, so a file with those characteristics tells you it has been through a messaging pipeline, not that anyone interfered with it.

Is my location hidden inside my recording?+

It can be. Phones with location access enabled for the camera or recorder write coordinates into MP4-family files as an ISO 6709 tag, accurate to a few metres. It is invisible in every ordinary player and file manager, which is why people send it to strangers without knowing. Drop the file here and the tool will say plainly whether it is there. To remove it, re-save the file through a converter that strips metadata.

What is a bext chunk?+

A block of provenance information inside a WAV file, defined by the European Broadcasting Union as part of Broadcast WAV. It holds an originator name, an origination date and time, a sample-accurate time reference, a unique material identifier and — most usefully — a coding history, to which each piece of equipment or software appends a line as it handles the file. Field recorders, broadcast systems and professional editing software write it; phone recorders and consumer apps essentially never do. When it is present it is usually the most informative thing in the file.

Can I use this tool's output in court?+

You can use it to understand a file and to decide what to ask for next. You should not present it as expert evidence, because it is not: it is a reading of labels, produced by an automated tool, with no examiner behind it. Formal proceedings need a qualified forensic audio examiner who can describe their method and be questioned on it. Rules on what is admissible and how a recording must be handled vary by jurisdiction, so ask a lawyer where you are rather than taking a general answer from a web page.

Why does the length shown here not match my player?+

Because they are measuring different things. Most players read the duration a file declares in its header. Where the format allows, this tool also counts the audio itself — MP3 frames, Ogg granule positions, FLAC's sample count — and reports both. A disagreement usually means the header was not updated after a trim, or the file was cut short during a copy. It does not indicate what the difference consists of.

Is my file uploaded anywhere?+

No. This page has no upload feature, no API route and no server behind it — your browser reads the file from your own disk and parses it in the tab. You can check: open your browser's developer tools, watch the Network panel, and drop a file in. Nothing carrying your audio appears, because there is nowhere for it to go. The site around the tool does load analytics, which measure page visits and never receive your file.

What audio formats does this read?+

MP4-family files (MP4, M4A, M4B, MOV, 3GP), WAV including Broadcast WAV, MP3 with ID3 tags and LAME encoder data, Ogg with Opus or Vorbis, FLAC, Matroska and WebM, and AMR. Files in formats it does not parse still get a report: their size, their opening bytes, what those bytes identify the format as, and whatever the browser's own decoder can add.

Does it work offline?+

Yes. Once the page has loaded, reading a file's metadata needs no network at all. Turn your Wi-Fi off and drop a file in — it works exactly the same, which is the clearest demonstration that nothing is being sent anywhere.

Free online audio converterStrip metadata, including location, without uploading anything.Free audio to textGet a transcript with timestamps, also on your device.Recording consent checkerWhich consent rules may apply where you and the others are.Audio evidence mistakesThe practical errors people make with a recording that matters.

The file you brought is missing what you need.

Most of what this page cannot tell you about a recording was lost after it was made, by something re-saving it. BlackBox timestamps every hour it records, keeps the original on your device, and never re-encodes it behind your back. Free on iPhone and Android.

Download on theApp Store Get it onGoogle Play

Planning space for long recordings? The audio storage calculator does the arithmetic.