Plist viewer: open a binary or XML .plist, or a .mobileprovision

What it shows

• Every value with its type: dict, array, string, integer, real, boolean, date, data and UID, plus the set and null that only binary plists can hold. Dicts keep their keys in file order. Long arrays open 500 items at a time, so a library of 20,000 tracks stays usable.
• Integers exactly. A JavaScript number, and so most web tools, rounds anything above 2⁵³ (9,007,199,254,740,992). Here integers are kept whole up to 64 bits and beyond. Apple's writer uses a 16-byte integer for values above 2⁶³−1, such as 18446744073709551615, and that is read too.
• Dates in UTC and in your own time zone. A binary plist stores a date as seconds, with a fraction, since 1 January 2001 UTC. An XML plist writes it as 2026-09-30T10:00:00Z.
• Data as bytes: the size, a hex dump with the printable characters beside it, base64, and a button to save the bytes as a file. Bytes that are themselves a binary plist or a DER certificate are pointed out.
• UIDs are the links inside an NSKeyedArchiver archive (how Cocoa apps save objects). Select one and jump to the $objects entry it points at.
• Search and key paths. Search every key and value, then copy a value's path in PlistBuddy form (:Entitlements:aps-environment) or in plutil form (Entitlements.aps-environment), ready for a script.
• Save as JSON or XML plist. JSON has no date, data or UID type, so dates become ISO 8601 UTC text, data becomes base64, and a UID becomes {"CF$UID": 7}. The page lists how many of each your file has. The XML file is Apple's own layout and opens in Xcode.

Provisioning profiles (.mobileprovision)

A profile is an XML plist wrapped in a CMS (PKCS#7) signature from Apple. The page unwraps it and shows the answers developers usually dig for with security cms -D -i:

• the app ID (team prefix plus bundle ID, or a wildcard such as ABCDE12345.*), the team name and ID, the profile's name and UUID;
• the expiry date with the days left (an installed app stops launching once its profile expires);
• the entitlements: push (aps-environment), keychain groups, app groups, iCloud, associated domains, get-task-allow;
• how many devices it lists (their UDIDs are in the tree: search for yours);
• each embedded developer certificate: its subject (for example Apple Development: Jane Tester (ZX9Y8W7V6U)), expiry, serial number and SHA-1 fingerprint, the name Keychain Access and Xcode use.

Where to find them: inside an app, at Payload/Name.app/embedded.mobileprovision in the .ipa (an .ipa is a ZIP file). On a Mac, profiles installed by Xcode 16 and later are in ~/Library/Developer/Xcode/UserData/Provisioning Profiles/, and by earlier versions in ~/Library/MobileDevice/Provisioning Profiles/. Each is named by its UUID.

Files it opens

A worked example: an iTunes library

The file iTunes-small.bplist from the node-bplist-parser project's tests is a 24,433-byte binary plist from iTunes 9.0.3. Its offset table lists 1,138 objects. The writer stores a repeated value once and points to it from each place it is used, so these unfold into 1,322 values in the tree. The root dict has 9 keys. :Tracks holds 42 tracks and :Playlists 13 playlists.

A search for castle finds :Tracks:100:Name, “Spanish Castle Magic” by Jimi Hendrix, and :Tracks:112:Name, “Castles Made Of Sand”, along with their file paths. Track 100 has two play dates. Play Date UTC is a real plist date, 2010-02-22 23:36:18 UTC. Play Date is a plain integer, 3349701378, that only makes sense as seconds since 1 January 1904 (the classic Mac OS epoch) in the computer's local time: 2010-02-22 16:36:18, seven hours behind UTC.

One playlist name, :Playlists:6:Name “90’s Music”, is marked as an ASCII string but holds the UTF-8 bytes of a curly apostrophe. Python's plistlib refuses the whole file because of it (“Invalid file”). This page reads it as UTF-8 and says so.

The same jobs on the command line

On a Mac: plutil -p file.plist prints any plist, and plutil -convert xml1 file.plist rewrites a binary one as XML, in place. plutil -convert json stops with “invalid object in plist for destination format” when the file holds a date or data. security cms -D -i profile.mobileprovision prints a profile's plist, and /usr/libexec/PlistBuddy -c "Print :Entitlements" file prints one entry, using the path this page copies. On Windows and Linux there is no plutil unless you install one; this page does the same reading in any browser.

What this cannot do

• No signature verdict. A profile's CMS signature is not verified, and its certificates are not checked against Apple's roots or for revocation, which needs the network. The page reads what the profile says; a tampered profile looks the same here. iOS itself refuses one whose signature is wrong.
• No editing. It reads and exports. It cannot change a value and write the plist back, and it cannot re-sign a profile.
• Old-style text plists are not read. The NeXTSTEP / OpenStep format ({ key = value; }) is named, not opened; plutil -convert xml1 turns it into XML. The newer private binary formats bplist15, bplist16 and bplist17 are named too.
• Archives are shown raw. An NSKeyedArchiver file appears as its $objects list and UID links, not rebuilt into the objects it saved (a colour, a font, a document).
• Exports cannot carry every type. JSON turns dates, data and UIDs into text (as listed above). XML plists have no null or set, and store dates to the whole second, so a binary file's fractional seconds are cut.
• Only the device list, not your device. A web page cannot read your iPhone's UDID. Copy it from Finder or Xcode's Devices window and search the tree for it.
• Memory. The whole file is read into the tab. Plists of a few hundred MB, like a huge iTunes Library.xml, may be too big for a phone.