Local ID3 Metadata Reader

How to use Local ID3 Metadata Reader

See the stored title, artist, album and other generic text frames rather than guessing metadata from a filename. This reader keeps source order, exact byte offsets, encoding and opaque frame omissions visible. It examines only the selected leading tag range; your audio tail is neither read nor decoded, and the original file is never rewritten.

1. Choose your own local file, or load the original standalone ID3 tag example. The example contains metadata only and is not a playable MP3.
2. Run the leading-tag inspection. Review decoded generic text frames alongside ordered byte ranges, flags and opaque payload omissions.
3. Copy or download the complete JSON evidence. Keep private tags private; no audio or destination is opened, played, uploaded or repaired.

Good to know

• One actual local file from 10 bytes through 64 MiB. Only the first 10-byte header and the declared leading tag are read. The tag payload is capped at 1 MiB, excluding its header and optional footer. The unread file tail is explicitly counted, not treated as validated audio. No MP3/MPEG codec, playback, duration, audio quality, copyright or ownership check is performed.
• Selected profile: ID3v2.3.0 and ID3v2.4.0 with plain tag headers. Extended headers, global unsynchronisation, experimental/reserved flags, other revisions, ID3v1, ID3v2.2 and appended-tag searches are unsupported. A v2.4 footer is allowed only when it exactly mirrors the header and there is no padding. Supported zero padding must be final and entirely zero.
• At most 256 frames with uppercase ASCII/digit identifiers, nonempty payloads and exact bounded lengths. Known status flags are reported without editing. Any nonzero payload-format flag refuses the tag: compression, encryption, grouping, per-frame unsynchronisation and data-length transformations are not guessed or executed.
• Generic T*** text frames, excluding TXXX, are decoded. A repeated generic text ID refuses instead of silently choosing one. TXXX, picture, comment, lyric, URL and unknown frame bodies receive ordered byte/flag inventory only; their contents are neither decoded nor exported. Other repeated IDs remain visible without interpreting their identity rules. This is source inspection, not full ID3 conformance or frame-specific semantic validation.
• v2.3 supports Latin-1 and UTF-16 with an initial BOM. v2.4 additionally supports UTF-16BE and strict UTF-8. Latin-1 maps each byte directly, including C1 codes; it is not Windows-1252. UTF-16 code-unit alignment and surrogate pairs are checked. Unicode decoding does not certify every historical Unicode-version restriction in an older tagging specification.
• v2.3 displayed text stops at the first aligned null terminator. Any remaining bytes are omitted from the result, with an ignored-byte count; they are not secretly decoded or exposed. v2.4 keeps null-separated text segments, including an empty final segment. For BOM UTF-16, one byte order is required; matching BOMs at later string starts are recognized and counted. UTF-8 and UTF-16BE preserve a literal leading U+FEFF. Whitespace, case, number/date/genre spelling and Unicode normalization remain unchanged.
• Each decoded text payload is capped at 65,536 bytes; at most 1,024 segments and 100,000 decoded UTF-16 units together. Complete JSON is capped at 500,000 UTF-16 units, including escaping. Unsupported or over-limit input returns no partial download. Control characters in decoded source remain escaped JSON data; they are never mounted as HTML or run as code.
• Each local tag-range read has a 5-second wait; a browser Blob read cannot be forcibly interrupted and late results are ignored. Parsing runs in one same-origin module Worker, with 10 seconds for fixed module preparation and a separate 2-second computation deadline. Tag bytes are copied before transfer; completion, errors and timeouts terminate Worker ownership and clear both timers.
• The original example is a genuine authored standalone ID3v2.4 tag, a use allowed by the ID3 format. It contains no MPEG audio and makes no promise that an arbitrary file tail is valid MP3. No source tag or file is changed, no URL from a tag is followed, and no input is uploaded or retained. The JSON can contain private metadata; review it before sharing.