What Are .plist Files on Mac? (And When to Touch Them)

A misbehaving Mac app, a forum post from 2019, and a single line of advice: “delete the plist file.” That’s the one piece of macOS troubleshooting that’s somehow survived from the OS X Tiger era to today. Sometimes it works. Sometimes it makes things worse. Sometimes it does nothing because plist files don’t quite live where they used to.

Plist files — short for “property list” — are how macOS stores structured data outside of databases. Preferences, configuration, app state, license info, system settings, the order of icons in your Dock — all of it is in plist files somewhere on your Mac. Understanding the format and the right tools to read and edit them is one of those skills that makes you legitimately better at macOS.

What a Plist Is

A plist is a structured data file. It can hold strings, numbers, dates, booleans, binary data, arrays, and dictionaries (key-value maps). The format is roughly equivalent to JSON or YAML, but it’s older than both and uses Apple’s own representation.

There are three plist formats in active use on macOS:

1. XML plist — human-readable, looks like XML
2. Binary plist — compact, faster to parse, not human-readable
3. OpenStep / ASCII plist — older, rarely seen anymore

Most modern macOS plists are binary. If you cat one, you’ll see what looks like garbage with bplist00 at the start. To see the contents in human form, use plutil.

Reading a Plist

The right tool to inspect a plist is plutil, which ships with macOS:

plutil -p /Library/Preferences/com.apple.SoftwareUpdate.plist

The -p flag prints the file in human-readable form. Output looks like:

{
  "AutomaticallyInstallMacOSUpdates" => 1
  "AutomaticDownload" => 1
  "LastFullSuccessfulDate" => 2026-04-15 09:23:14 +0000
  "ScheduledFrequency" => 1
}

To convert a binary plist to XML so you can read or grep it:

plutil -convert xml1 -o /tmp/converted.plist /Library/Preferences/com.apple.SoftwareUpdate.plist

Now /tmp/converted.plist is plain XML you can open in any text editor.

To convert back:

plutil -convert binary1 /tmp/converted.plist

Most plist files on macOS are binary because parsing is faster, but the system handles both formats transparently — you can swap one for the other and macOS won’t care.

Where Plists Live

Plist files are scattered across the system. The main locations:

• ~/Library/Preferences/ — per-user app preferences
• /Library/Preferences/ — system-wide app preferences
• ~/Library/Application Support/<app>/ — app-specific config (often .plist here too)
• ~/Library/Containers/<bundle.id>/Data/Library/Preferences/ — sandboxed app preferences (more on this in a moment)
• ~/Library/LaunchAgents/ and /Library/LaunchDaemons/ — launchd job descriptions
• /System/Library/Preferences/ — Apple system defaults
• Inside every .app bundle: Contents/Info.plist — describes the app

Nearly every directory in /Library and ~/Library has at least one plist file in it. Some apps store dozens.

Power users use SweepSweep handles all the cleanup that articles like this describe. Get Sweep free →

The Sandboxing Twist

This is where the “delete the plist” advice from old forum posts goes wrong. Since macOS Catalina, sandboxed apps (anything from the Mac App Store, plus many third-party apps that opted in) store their preferences in a different location:

~/Library/Containers/<bundle.id>/Data/Library/Preferences/<bundle.id>.plist

So for the Notes app, the preferences plist isn’t at ~/Library/Preferences/com.apple.Notes.plist — it’s at ~/Library/Containers/com.apple.Notes/Data/Library/Preferences/com.apple.Notes.plist.

You’ll often find an empty or stub plist at the old location and the real one inside the container. Editing the wrong one does nothing. The system reads the container’s copy.

To find the actual plist for an app, use find:

find ~/Library -name "com.example.app.plist" 2>/dev/null

That’ll list every plist file matching that bundle ID across both sandboxed and non-sandboxed locations.

Editing Plists Safely

Three tools, in order of safety:

1. The defaults command (safest)

defaults is Apple’s intended way to read and write plist preferences. It handles type coercion, locking, and notifying running apps that preferences changed.

To read a value:

defaults read com.apple.dock orientation

To write:

defaults write com.apple.dock orientation -string "left"

To delete a key:

defaults delete com.apple.dock orientation

To see everything in a domain:

defaults read com.apple.dock

defaults is the right tool for almost any preference change. It’s safer than directly editing files because it goes through the same APIs the system uses, so it can’t corrupt the file format.

2. PlistBuddy (more powerful, slightly riskier)

/usr/libexec/PlistBuddy lets you operate on a plist file directly with a richer command syntax. It’s useful for plists that aren’t preferences (like Info.plist files inside app bundles, or launch daemon plists).

Read everything:

/usr/libexec/PlistBuddy -c "Print" /Library/LaunchDaemons/com.example.helper.plist

Read a specific key:

/usr/libexec/PlistBuddy -c "Print :ProgramArguments:0" /Library/LaunchDaemons/com.example.helper.plist

Set a value:

sudo /usr/libexec/PlistBuddy -c "Set :KeepAlive true" /Library/LaunchDaemons/com.example.helper.plist

The colon-separated paths can navigate into arrays and nested dictionaries.

3. Direct text editing (riskiest)

Convert a binary plist to XML, edit it in any text editor, and convert it back. This is fine for one-off edits but easy to mess up — a single typo breaks the file and the app falls back to defaults.

If you’re going to do this, always make a backup first:

cp ~/Library/Preferences/com.example.app.plist ~/Desktop/com.example.app.plist.bak

When Deleting a Plist Helps

The “delete the plist” troubleshooting trick works because most apps regenerate their preferences file with defaults if they don’t find one. So if a corrupted preference is causing weird behavior, deleting the plist resets the app’s settings without uninstalling anything else.

It’s the right move when:

• An app launches and immediately crashes (corrupt preferences)
• A setting in the app’s UI doesn’t apply (something else is overriding it)
• An app’s window won’t show on screen (saved window position is off-screen)
• An app keeps reverting to a state you don’t want

Steps:

1. Quit the app completely (Cmd+Q, verify with Activity Monitor)
2. Find the plist (check both ~/Library/Preferences and ~/Library/Containers/<bundle.id>/Data/Library/Preferences)
3. Move it to the Desktop instead of deleting (so you can put it back if needed)
4. Relaunch the app
5. If it works, you can delete the moved file

A subtlety: macOS caches preference values in memory through the cfprefsd daemon. Just deleting the file may not be enough if the daemon still has the cached values. Killing cfprefsd for your user — or simply rebooting — clears the cache.

killall cfprefsd

There’s a faster waySweep does this kind of cleanup automatically. Try Sweep free →

When Deleting Makes Things Worse

Plist files don’t only hold preferences. Sometimes they hold license keys, authentication tokens, or app-critical state. Deleting the wrong plist can:

• Sign you out of an app you’ll then need to log back into
• Remove a paid license, requiring re-entry of an activation code
• Lose your work-in-progress state for an app that doesn’t autosave to a separate file
• Break an app entirely if it depends on the plist for migration or schema info

Especially risky to delete:

• Anything in ~/Library/Application Support/<app>/ (often holds real data, not just preferences)
• Plists for apps with subscriptions or licenses
• Anything labeled with words like “license,” “registration,” “auth,” “token,” or “session”

The right approach: read the plist first with plutil -p and see what’s in there. If it’s all small key-value pairs that look like UI state (“LastWindowSize,” “ShouldShowWelcome”), it’s probably safe to delete. If you see what looks like serialized state, license data, or large binary blobs, leave it alone.

launchd Plists Specifically

Launch agent and launch daemon plists in ~/Library/LaunchAgents, /Library/LaunchAgents, and /Library/LaunchDaemons are a special category. These tell launchd to run programs in the background.

If you want to inspect one:

plutil -p /Library/LaunchDaemons/com.example.helper.plist

If you want to remove the corresponding job entirely, you need both to unload it from launchd and delete the file:

sudo launchctl bootout system /Library/LaunchDaemons/com.example.helper.plist
sudo rm /Library/LaunchDaemons/com.example.helper.plist

Just deleting the file without unloading first leaves the running process active until reboot.

The Info.plist Inside Every App

Every macOS app bundle has an Info.plist at Contents/Info.plist. This is metadata: the app’s name, version, bundle identifier, what file types it handles, what permissions it requests.

You can read any app’s Info.plist:

plutil -p /Applications/Safari.app/Contents/Info.plist | head -30

You’ll see things like CFBundleIdentifier (Safari’s is com.apple.Safari), CFBundleVersion, CFBundleShortVersionString, and the permission descriptions for things the app might ask access to.

Editing an app’s Info.plist is almost never the right move — it’ll break the app’s code signature and macOS will refuse to launch it. The exception is your own apps that you’re developing.

What This Skill Buys You

Once you can read and edit plists confidently, a lot of macOS troubleshooting opens up:

• Reset misbehaving apps without uninstalling them
• Inspect what a launch agent is actually doing
• Read the metadata of any app you’ve installed
• Tweak hidden preferences via defaults write (a whole category of “secret” macOS settings)
• Audit what an installer dropped in your library

It’s the difference between blindly running fix-it scripts from the internet and actually understanding what they do. Most of the time you don’t need to touch plists. When you do, the right tool isn’t a generic text editor — it’s plutil, defaults, and PlistBuddy, used carefully and ideally with a backup.