plutil on Mac: -bool 1 Saves false, a Bad -date Crashes

I ran plutil -replace Flag -bool 1 test.plist on this Mac mini and then read the value back. It was false. Exit code 0, nothing on stderr. A few minutes later plutil -replace When -date 2026-10-07 test.plist exited with status 133, printed nothing at all, and left a crash report in ~/Library/Logs/DiagnosticReports.

plutil is the property list tool that ships with every Mac, and I lean on it constantly: reading launchd jobs, pulling keys out of system bundles, checking files before launchctl sees them. So I spent a session testing every verb and value type on macOS 26.4.1 to find where it quietly does something other than what the help text suggests. Below are the results, the source code that explains them, a count of how many real system plists can't be converted to JSON, and the 25 Stack Exchange questions with plutil in the title, sorted by what went wrong.

What plutil is, and which plutil you have

/usr/bin/plutil on this machine is 663,776 bytes, and its help text starts with a line I hadn't noticed before: Running in Swift mode. Apple rewrote plutil in Swift, and the rewrite is public in the swift-corelibs-foundation repository (commit titled "Rewrite plutil for parity with all Darwin functionality", April 2025). I can't prove the macOS binary is built from that exact file, but 62 of the 63 lines of plutil -help on this Mac appear word for word in its PLUContext.swift, and the crash report names the same function, InsertCommand.execute(). Where I quote source below, it's from that file.

It reads and writes three formats: XML (xml1), binary (binary1) and JSON. It can also print Swift or Objective-C literals. The verbs are -lint (the default), -convert, -insert, -replace, -remove, -extract, -type, -create and -p.

Typed values: what plutil stores when you pass something odd

Each -insert or -replace takes a type flag and a value. I fed each type a list of inputs and read the result back with plutil -extract KEY raw. Every row below exited 0 unless marked.

Type flag	Input	Stored value
-bool	YES, yes, Yes, true, True, TRUE	true
-bool	1, y, on	false
-integer	12abc / 1.9 / 1e3	12 / 1 / 1
-integer	0x10 / abc	0 / 0
-integer	9223372036854775808	9223372036854775807 (clamped)
-float	abc / nan / inf	0.000000
-date	2026-10-07T10:30:00Z	2026-10-07T10:30:00Z
-date	2026-10-07, "2026-10-07 10:30:00", 2026-10-07T10:30:00+09:00, garbage	crash, exit 133, file unchanged
-data	notbase64!	"Invalid base64 data in argument", exit 1
-data	(empty string)	empty data, exit 0

The source explains all of it. The bool branch is two string comparisons:

if boolValue.lowercased() == "true" || boolValue.lowercased() == "yes" {
    value = NSNumber(value: true)
} else {
    value = NSNumber(value: false)
}

Anything that isn't "true" or "yes" in some capitalization becomes false, including 1. The help text does say this ("YES if passed "YES" or "true", otherwise NO"), but 1 means true almost everywhere else, including in PlistBuddy: PlistBuddy -c "Set :Flag 1" on the same file stored true.

Integers go through NSString.integerValue, which reads leading digits and stops at the first character it doesn't like. Hex isn't understood, so 0x10 becomes 0. Floats use doubleValue, which turns anything unparseable into 0. Neither reports an error.

Dates are parsed by building a one-key XML plist around your string and parsing that:

let xmlPlistDict = try? PropertyListSerialization.propertyList(from: xmlPlistData, format: nil)
value = (xmlPlistDict as! [String: Any])["value"]!

The try? swallows the parse error and turns it into nil, and the forced cast as! on nil stops the program. That's the exit 133 (128 + SIGTRAP) with an empty stderr. The crash report says EXC_BREAKPOINT in InsertCommand.execute(), and each failed attempt wrote a new plutil-*.ips file. The only format that works is the XML plist one: YYYY-MM-DDTHH:MM:SSZ, in UTC, with the Z. An offset like +09:00 crashes it too.

plutil -convert json fails on one date or data value

The most common reason to reach for plutil is to turn a plist into JSON so jq can read it. That works only when the file contains no <date> and no <data>, because JSON has neither type. One of either, at any depth, fails the whole file:

$ plutil -convert json -o - t.plist
t.plist: Invalid object in plist for JSON format
$ echo $?
1

The message doesn't name the key. Without -o, plutil converts in place, and on failure it leaves the file alone (the checksum was identical before and after). JSON output also escapes every forward slash, so a URL comes out as https:\/\/picklog.cc\/a\/b. That's valid JSON, just surprising if you grep it.

To see how often this bites, I ran plutil -convert json over the plists on this Mac that I could read without root:

Set	Files	Converted	Failed
/System/Library/LaunchDaemons	422	422	0
/System/Library/LaunchAgents	464	464	0
CoreServices app Info.plist	116	116	0
/System/Applications Info.plist	65	64	1 (Stocks.app, data)
/Library/Preferences (readable)	37	27	10 (6 date, 4 data)

Bundle and job definitions are almost all JSON-safe: 1,066 of 1,067. Preference files are not. com.apple.SoftwareUpdate.plist alone holds 14 dates (last scan, last success and so on), so the file most people want to inspect is one plutil won't hand to jq. Three more preference files (com.apple.TimeMachine.plist among them) were unreadable without root, and I left them out.

Two workarounds that worked here. For a single value, skip JSON: plutil -extract LastSuccessfulDate raw /Library/Preferences/com.apple.SoftwareUpdate.plist printed 2026-10-07T11:36:39Z. For the whole file, the Python that comes with the Command Line Tools can do the conversion with a fallback for the two missing types:

/usr/bin/python3 -c 'import plistlib,json,sys,base64,datetime
d=lambda o: o.isoformat() if isinstance(o,datetime.datetime) else base64.b64encode(o).decode()
print(json.dumps(plistlib.load(open(sys.argv[1],"rb")),default=d))' /Library/Preferences/com.apple.SoftwareUpdate.plist

Note that plistlib returns dates without a timezone. They are UTC, so 2026-10-07T23:37:18 in that output is 08:37 the next morning in Seoul.

The reverse direction has the mirror problem. A JSON file containing null fails -convert xml1 with "Invalid object in plist for property list format". Numbers keep their JSON form: 1 becomes <integer> while 1.0 and 1e3 become <real>, which matters for keys that launchd expects as integers.

-extract: dots, scalars and raw output

Key paths split on dots, so a key that contains dots isn't found: plutil -extract com.apple.dotted raw returned "No value at that key path or invalid key path". Escaping each dot with a backslash works for both reading and writing: plutil -extract 'com\.apple\.dotted' raw t.plist printed the value, and -replace with the same escaped path changed it. A numeric component is an array index, but a dictionary key that happens to be 123 still worked as a key.

-extract KEY json fails on any single value that isn't an array or dictionary. Extracting a plain string as JSON gave the same "Invalid object in plist for JSON format" message that dates produce, which sent me looking for a date that wasn't there. For scalars use raw, which prints strings as-is, bools as true/false, floats with six decimals (1.000000), dates as UTC RFC 3339, data as base64, a dictionary as its keys one per line, and an array as its item count. Add -n to drop the trailing newline, and -expect integer to fail with "Value at [Label] expected to be integer but is string" when the type is wrong.

-insert vs -replace, and arrays

• -insert on an existing key fails: "Value already exists at key path Label". -replace overwrites or creates.
• Neither creates parent dictionaries. -insert New.Deep with no New failed with "Key path not found New.Deep". PlistBuddy's Add :New:Deep string v created both levels.
• -insert Arr.0 inserts at the front and shifts the rest. An index past the end fails ("Index 5 out of bounds"). Use -insert Arr -string x -append to add at the end.
• -json '{"a":null}' fails for the same null reason as above.

Editing keeps the file's format: a binary plist edited with plutil stayed binary, and a JSON file edited with -replace stayed JSON. PlistBuddy doesn't. Setting one key in a binary plist rewrote it as XML, and it refused to open the JSON file at all ("Error Reading File"). PlistBuddy also returned exit 0 after printing "Unrecognized Date Format" for a date it didn't add, so its exit code isn't proof of a write either.

plutil -lint says OK, launchctl says error 5

-lint checks syntax only. To show the gap, I wrote three launchd plists that are valid property lists but bad jobs: one without a Label, one with ProgramArguments as a string instead of an array, and one whose Label is an integer. All three printed OK from plutil -lint, and all three failed launchctl bootstrap gui/501 with "Bootstrap failed: 5: Input/output error". I mapped the other causes of that error in launchctl load failed 5: Input/output error. Lint also won't catch a misspelled key, which is how a WeekDay typo silently changed when a job fired in launchd StartCalendarInterval missed. And -lint rejects valid JSON outright ("Unexpected character { at line 1") even though -convert reads the same file fine.

This gap is the biggest group in the Stack Exchange questions. I pulled every question with plutil in the title from five sites through the API: 25 questions, 83,253 views in total (Stack Overflow 17, Ask Different 7, Super User 1, Unix & Linux and Server Fault 0). Five of the seven on Ask Different, with 21,602 views between them, are some form of "launchctl says plist is invalid, plutil says it's OK". Most of the Stack Overflow ones are about reading or writing a specific key, led by getting info from plutil at 16,138 views, and the dot-escaping and array-index rules above answer most of them.

One trap that didn't reproduce

A common warning is that editing a file in ~/Library/Preferences directly is pointless because cfprefsd serves a cached copy. I wrote a test domain with defaults write, changed it with plutil -replace, and defaults read returned the new value immediately. No app had that domain open, so this doesn't rule out the cache problem for a running app's preferences; it only shows that plutil edits aren't automatically lost. For anything an app is using, defaults write is still the safe route. If you set environment variables for launchd jobs this way, the details of what a job actually receives are in launchd plist environment variables.

FAQ

How do I convert a plist to JSON on a Mac?

Run plutil -convert json -o - file.plist to print JSON without touching the file. If it fails with "Invalid object in plist for JSON format", the file contains a date or data value, which JSON can't represent. Extract single values with plutil -extract KEY raw, or convert the whole file with Python's plistlib and a fallback for dates and bytes.

How do I set a boolean with plutil?

Use plutil -replace KEY -bool true file.plist (or YES, in any capitalization). Any other value, including 1, is stored as false without an error.

What is the difference between plutil and PlistBuddy?

plutil can read and write XML, binary and JSON and keeps a file's format when editing, but it uses dot-separated key paths and won't create missing parent keys. PlistBuddy uses colon-separated paths, so dotted keys need no escaping, and creates parent dictionaries, but it can't read JSON, rewrites binary plists as XML, and can return exit 0 after an error.

Method: all tests ran on 2026-10-07 between 19:30 and 19:45 KST on a Mac mini M4 (Mac16,10, macOS 26.4.1 build 25E253, /usr/bin/plutil 663,776 bytes) against test files in a scratch directory; the conversion census of /System and /Library/Preferences ran on 2026-10-08. Each stored value was read back with plutil -extract, and file changes were checked with shasum. Source quotes are from Sources/plutil/PLUContext.swift in swift-corelibs-foundation on its main branch, matched against this binary's help text and crash report, not against Apple's internal build. The launchd test plists were bootstrapped into my own GUI domain and none loaded. User preference files in my home folder were excluded from the census after a read of one of them stalled. The Stack Exchange numbers come from the API search for "plutil" in titles on 2026-10-07, and the man page is plutil(1).