Property List (plist) Converter

Parse Apple Property List files (XML/binary plist) and convert to JSON or YAML.

Tested tool guide Tested browser tools Checked August 16, 2026

What Property List (plist) Converter does, with a checked example

macOS and iOS store configuration in property lists, and they come in two unrelated formats: XML (readable text) and binary (starting with the magic bytes bplist00, mostly non-text). This tool parses either into a typed value tree - dictionaries, arrays, strings, numbers, booleans, dates, and raw data - and serializes it as JSON or YAML for pasting into scripts, editors, or version control. Everything runs in the browser; the file never leaves your machine. The surprise most people hit: JSON has no date or binary type, so timestamps and data blobs come out as strings, and nothing in the output marks which strings were dates.

Worked example

A concrete input and expected output from the current implementation.

Input

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>AppName</key>
    <string>Notes</string>
    <key>Version</key>
    <integer>42</integer>
    <key>AutoSave</key>
    <true/>
    <key>Tags</key>
    <array>
        <string>work</string>
        <string>personal</string>
    </array>
</dict>
</plist>

Expected output

{
  "AppName": "Notes",
  "Version": 42,
  "AutoSave": true,
  "Tags": [
    "work",
    "personal"
  ]
}

Each plist element maps to its JSON type: dict to an object, string to a string, integer 42 to the number 42, true to the boolean true, and the array to an array of strings. Key order follows the file.

How the result is produced

Two formats, one value tree

The XML format is plain markup: a plist root element wrapping typed elements - dict, array, string, integer, real, date, data, true, false - that nest into a tree. The binary format is different: a bplist00 magic number, an offset table of encoded values, and a trailer that points at the table. Decoding a binary plist means resolving those offsets into the same tree of plist types.

Mapping to JSON and YAML

Each plist type has a JSON counterpart: dict to object, array to array, string to string, integer and real to number, true and false to boolean. Dates and raw data have no JSON type, so they surface as strings. Binary plists store dates as seconds since 2001-01-01 UTC, 978307200 seconds before the Unix epoch, so a raw timestamp is off by 31 years to Unix-aware tooling. YAML follows the same mapping.

Good uses

You dumped a preference or config file - from ~/Library/Preferences, defaults read output, or an iOS app container - and the script, dashboard, or pipeline that consumes it only accepts JSON.
You need a readable, diffable copy of an Info.plist or exported plist for version control or review: a binary plist is an opaque blob to diff tools, while the JSON output shows every key and value.
You want to manage configuration as YAML: convert the plist once, then edit and template it with tools that speak YAML natively.

Limits and checks

The conversion is not lossless. JSON has no date or binary type, so the plist's dates and data blobs can only appear as strings, and the output does not say which strings were dates, which were base64 data, and which were plain text.
Many binary plists from app containers are NSKeyedArchiver archives, not plain data. A keyed archive encodes an object graph under reserved keys - $archiver, $version, $objects, $classes, $class, and CF$UID references - rather than a flat list of values. Unarchiving - recovering the original objects - is a different operation from converting a plist: it requires the classes that wrote the archive.
Plist integers are 64-bit, but JSON numbers are exact only up to 2^53 (9007199254740992). Values at or beyond that, common for timestamps and identifiers, may be rounded in the output; re-check large integers.

Common questions

My file starts with bplist00. Can I just paste it in?

No - a binary plist is not text. It contains NUL bytes and other arbitrary byte values, so pasting garbles or truncates it. Select the file itself so the tool reads the raw bytes; the bplist00 header and trailer are what the decoder works from. XML plists are plain UTF-8 text and paste fine.

Why is my date about 31 years off?

Binary plists store dates as seconds since 2001-01-01 00:00:00 UTC, not the Unix epoch of 1970; the difference is exactly 978307200 seconds. A raw value like 736100000 means 2024-04-29 16:13:20 UTC once that offset is applied. If you see such a number where you expected a date, it is the epoch offset, not a parser bug.

References and verification

The example and behavioral notes were checked against the browser implementation. Standards and primary references below define the relevant format, formula, or platform behavior.