What this binary plist inspector checks
The parser verifies the eight-byte bplist00 header and the 32-byte trailer, then uses the declared integer widths and object count to audit every offset-table entry. It parses simple values, integers, reals, dates, data, ASCII and UTF-16BE strings, UIDs, arrays, sets, and dictionaries while checking markers, extended counts, byte bounds, reference IDs, dictionary key types, duplicate keys, and object-range overlap.
Object identity, sharing, and reachability
A binary plist stores objects once and lets containers refer to them by number. Repeated references can therefore represent intentional shared values; the report counts incoming edges rather than flattening them away. It follows the top object to assign readable first paths, reveals unreachable records, and detects cyclic references without recursively expanding an unsafe or misleading value tree.
Physical layout evidence
The layout summary separates the eight-byte header, object table, offset table, and trailer. Each object row preserves its marker, exact start byte, parsed record length, declared count, and bounded preview. Gaps, duplicate or out-of-order offsets, overlapping object records, and bytes between the offset table and trailer remain visible instead of being silently normalized.
Validation boundary
A clean structural report does not prove the plist is safe, authentic, complete, or accepted by a particular Apple application. This tool does not interpret application-specific keys, keyed archives, NSKeyedArchiver classes, bookmark data, serialized objects, embedded payload semantics, signatures, or provenance. It does not recover deleted values, edit or convert files, or reproduce every permissive behavior of Foundation. Use plutil, the relevant application, and forensic tooling when authoritative compatibility or interpretation matters.
Frequently asked questions
Is my plist uploaded?
No. The file is read locally by browser JavaScript and is not sent to ToolQuill or another service.
Why not just convert the file to XML or JSON?
Conversion hides physical offsets, shared object identity, unreachable records, malformed references, and layout anomalies. This page is intended for structural diagnosis rather than format conversion.
Why can one object have multiple incoming references?
Container entries point to object numbers. Two array positions or dictionary values can deliberately point to the same stored object, saving space and preserving object identity.
Does it support XML property lists?
No. XML plists are readable text and have different structural concerns. This inspector targets the binary object-table representation beginning with bplist00.
Authoritative implementation references
The parser follows the trailer, offset, marker, and reference behavior documented in the Swift project's Apple-authored CoreFoundation binary plist implementation and the Apple Swift Binary Parsing example. Apple's Foundation documentation identifies binary property lists as a supported serialization format.
Inspect an OLE/CFB container · Diagnose text encoding · Browse legacy-data tools