What defaults write does, and how to undo one safely

9 September 2026 · 6 min read

defaults is a command-line front end to the preferences system that System Settings and every Mac app already use. defaults write stores a value under a key in one app’s preference domain; nothing is compiled in, nothing is patched, and the clean undo is defaults delete with the same domain and key, which removes your override and lets the app go back to its built-in behavior.

The part people skip is reading the current value first. That is the whole difference between a change you can reverse and a guess you have to live with.

Domains, keys and where they live

A domain is one app’s bucket of settings, named by its bundle identifier: com.apple.finder, com.apple.dock, com.apple.screencapture. Settings shared by every app live in the global domain, which you can name three ways in a command: NSGlobalDomain, -globalDomain or -g. They are the same thing.

Inside a domain are keys with values, and each value has a type: boolean, integer, float, string, array or dictionary. On disk it is a property list under ~/Library/Preferences, but do not edit those by hand: a background process caches preferences in memory and can write its copy back over your edit.

To see what exists:

defaults domains
defaults read com.apple.finder
defaults find screenshot

The first lists every domain, the second dumps one, the third searches keys and values across all of them. defaults find locates a setting when you know roughly what it is called but not which app owns it.

Read before you write

Before changing a key, ask what it is now:

defaults read com.apple.finder _FXShowPosixPathInTitle
defaults read-type com.apple.finder _FXShowPosixPathInTitle

One of three things happens. It prints a value, in which case write that value down. It prints does not exist, which is useful information: there is no override, the app is using its own default, and the clean undo later will be to delete the key again. Or it prints a type you did not expect, which is your warning that the command you were about to paste has the wrong type in it.

For anything you are about to change more than one key in, take a copy of the whole domain first:

defaults export com.apple.finder ~/Desktop/finder-before.plist

Restoring it later is the mirror image:

defaults import com.apple.finder ~/Desktop/finder-before.plist
killall Finder

That is the closest thing to an undo button the command has, and it takes two seconds.

The three ways to undo

Delete the key. The right answer almost always:

defaults delete com.apple.finder _FXShowPosixPathInTitle

This removes your override. The app returns to whatever it does out of the box, including if Apple changes that default in a later macOS version.

Write the old value back. Correct when the key genuinely had a value before you touched it, and you recorded it. Use the same type flag you read.

Delete the whole domain. defaults delete com.apple.finder with no key erases every preference that app holds, not only yours: window positions, view settings and sidebar contents go too. A real option when a domain is in a mess, and a blunt one. Restore from an export instead if you have one.

Writing false is not the same as deleting. It pins the value, so if the default ever changes, your Mac keeps the old behavior for reasons nobody will remember.

Making the change actually appear

Apps read preferences when they start. Changing a key under a running app usually does nothing visible, and worse, the app may write its own in-memory copy back on quit and wipe what you did.

The safe order: quit the app, run the command, open the app again.

For the parts of macOS you cannot quit normally, restart the process:

killall Finder
killall Dock
killall SystemUIServer

Restarting Finder blinks the Desktop and brings your windows back; neither command loses work. For anything else, logging out and back in covers it. Quit System Settings before running commands too, because an open pane can rewrite the key you just changed.

Both keeping folders at the top of Finder windows and showing the full path in the Finder title bar are one write plus one killall Finder.

The traps worth knowing

Nothing validates your command. defaults write accepts a key no app has ever read, and reports success. A command from an old blog post can name a key Apple removed three versions ago, and you get no error at all, only the absence of an effect.

Type mismatches fail quietly. -bool false and -string false are not the same, and an app expecting a boolean will usually ignore the string.

Sandboxed apps keep preferences in their container. Writing to a domain name for a sandboxed app can create a file in ~/Library/Preferences that the app never reads, because its real preferences live under ~/Library/Containers. If a change to a Mac App Store app does nothing, this is usually why.

Some settings are not preferences at all. Privacy permissions, keychain contents and per-folder Finder view settings live in databases and hidden files, not plists. defaults cannot touch them.

On a managed Mac, a profile wins. If your employer pushes a configuration profile, its values override yours and your change reverts. Nothing is broken.

A routine that keeps you out of trouble

1. Quit the app, and quit System Settings.
2. defaults read-type and defaults read the key. Note what it says, including does not exist.
3. defaults export the domain to your Desktop if you are changing more than one thing.
4. Make one change.
5. Restart the app or killall the process.
6. Check the result before moving on.
7. Undo with defaults delete, or import your export.

One change at a time is the part that matters. Five commands pasted together, one of which is for a key that no longer exists, is how an afternoon disappears.

When a settings app is the better tool

On a machine you set up once, the commands are fine and free. If you change settings often, or on machines other people use, the record is the valuable part. Mainspring wraps 90 or so of these settings as labeled switches, snapshots the previous value before each change, and reverts in a click. That is the routine above with the note-taking done for you. It is $29 once for up to three Macs, with a free day to see whether the settings you want are among them.

Questions

Is defaults write dangerous? For user-level domains, not particularly: the realistic worst case is an app behaving oddly until you delete the key. It becomes riskier when a command starts with sudo, because that writes system-wide preferences affecting every account.

I ran a command from a blog post and nothing happened. Most likely the key no longer exists in your version of macOS, the app was running at the time, or the app is sandboxed and its preferences are in a container. Check with defaults read-type: if the key does not exist after your write, the write went somewhere the app is not reading.

Can I reverse everything I have ever changed? Not automatically. There is no log of your writes, which is why the export step matters and why a note of what you changed beats trying to remember.

Do these settings survive a macOS update? User preferences generally carry across updates. What does not survive is a key Apple stops reading, and those go quietly. If a tweak stops working after an update, the setting behind it is usually gone rather than reset. Turning off autocorrect and smart quotes is one that has stayed stable for years.