What is the Finder pref for window column width?

So since forever I’ve suffered from this issue that Finder across reboots does not preserve my desired window position, size and column width (my default Finder window is column view).

In the past I wrote an Apple Script that just sets these attributes and I run that script (as a self-contained app) whenever Finder restarts.

But since we just had this discussion about changes in the way app preferences are handled since Mojave, it occurred to me that I should just edit the Finder’s preferences (using cfprefs of course) to adjust its defaults for window position, size, and column width to whatever I want.

So this is my question. What is the key for the column width in Finder? I can see a gazillion keys in my Finder prefs, and just going through the list I’ve spotted several that could be it, but I’m not certain. Any ideas?

Or, on a related note, is there a straightforward way to lookup the mapping between an AppleScript property (as in: set the column width of the front Finder window to 206) and what it is actually modifying in terms of Finder pref?

1 Like

I know many of you are programmers or at least conversant in AppleScript. For the rest of use, there is Pathfinder 10.

You can have multiple tab sets and window layouts and leave Apple’s 36-year-old Finder in the trash can of history.

You can try a full-featured demo for 30 days, and another 60 day money-back guarantee. Here is my guarantee. Use it for 90 days risk-free, and I guarantee you will never go back to Apple’s ancient Finder.

Unless you are a code hacker and enjoy the frustration and the need to post How-To questions in this thread.

I’ve tried Pathfinder time and time again but just can’t find a way to like it. I have a license and use it occasionally as I like it’s permissions and attributes modules, but I can’t see myself ever using it as a total Finder replacement. I’m sure others will, but it’s never won me over.

I fell foul of some reliability issues over the years but I probably haven’t used PF10 enough to know if they’ve been resolved. I think it was primarily PF8 and PF9.

1 Like

I have hardly ever had any reliability issues, mostly display bugs. Great support from them.

Sorry to hear it didn’t meet your needs. Personally I feel that the Finder is too simplistic. It pains me to use only Finder.

Um OK, back on topic, any suggestions at all?

My Finder has about 400 key/value pairs listed, of which maybe 2 dozen could be the column width. There must be a better way to figure this out than me trying each one of those parameters to determine which one it actually is. :laughing:

You could try writing a script that captures all of the Finder preferences before and after setting the column width and compare the two.

I use to use Pathfinder, but I went back to Finder about three years ago. PathFinder never was able to handle iCloud documents, and then I started having issues with the Desktop where PathFinder didn’t update the file information unless I restarted it.

I got PathFinder for programming support and because it had things like being able to show the User’s library directory. The biggest feature was tabbed windows.

However, Finder does tabs, and the lack of iCloud support really hurt. I ended up going back to Finder. There are missing features in Finder like Move a file rather than just Copy it, (Yes, I know the move is there if you press some key while pasting it, but such a feature should be a first class issue and not something hidden behind a key press). But, over all, I don’t really miss Pathfinder.

I’ve always assumed that info is in the .DS_Store file in a folder, not in a Finder preferences file, but I can’t recall why I think that. The window size and position are generally saved for me (but not always), and column width is sometimes saved, but rarely. I haven’t figured out the magic sequence of events to get everything saved always.

This is a really good suggestion. Alas, it’s a lot harder to implement these days. Before cfprefs you could have just done a diff of the com.apple.Finder.plist file before and after setting the column width and you’d be done. These days that won’t work anymore so instead you’d need to somehow grab all prefs and dump them to a file by hand. I can’t say it’s immediately obvious to me right now how to do that. I’d like to believe there’s a much simpler way. Prefs Edit is a very nice little app, but it does not offer any kind of dump to flat file functionality.

Actually, it does, but it appears to be undocumented,

Open a plist. Select one or more properties (or select them all with CMD-A). Then copy (CMD-C) from Prefs Edit and paste into your favorite text editor. You’ll get an XML representation of all the properties you copied.

I tested this with Emacs and with TextEdit.


It looks like the command-line defaults tool can do this.

To dump all of the preferences system-wide (massive amounts of data), use defaults read:

$ defaults read
    ".GlobalPreferences_m" =     {
    "Apple Global Domain" =     {
        AKLastEmailListRequestDateKey = "2022-01-31 03:14:11 +0000";
        AKLastIDMSEnvironment = 0;
        "AMD4.Clock" = "1.603401e+09";
        AppleAccentColor = 4;

To dump all of the preferences in a single domain, use defaults read followed by the name of the domain. For instance, to see TextEdit preferences (com.apple.TextEdit domain):

$ defaults read com.apple.TextEdit
    AVPlayerViewShowsDurationInsteadOfTimeRemainingDefaultsKey = 1;
    NSFontPanelAttributes = "1, 0";
    NSNavLastRootDirectory = "~/Desktop";
    NSNavLastUserSetHideExtensionButtonState = 1;

A domain can also be specified by application name with the -app argument:

$ defaults read -app TextEdit
    AVPlayerViewShowsDurationInsteadOfTimeRemainingDefaultsKey = 1;
    NSFontPanelAttributes = "1, 0";
    NSNavLastRootDirectory = "~/Desktop";
    NSNavLastUserSetHideExtensionButtonState = 1;

But this doesn’t seem to work for all applications. For instance, -app finder gives me an error, even though the com.apple.finder domain works. I suspect the human-visible application names aren’t always the names used internally by the OS.

Finally, you can specify the path to the plist file holding the preferences (must be an absolute path - beginning with either a / or a ~ character) instead of a domain or app name:

$ defaults read ~/Library/Preferences/com.apple.TextEdit.plist
    NSNavLastRootDirectory = "~/Documents/Word Processing docs";
    NSNavLastUserSetHideExtensionButtonState = 0;
    NSNavPanelExpandedSizeForSaveMode = "{712, 473}";

Notice how this isn’t the same information as what we got from com.apple.TextEdit or -app TextEdit. That’s because the application isn’t actually using that file - it’s a leftover preference file from some earlier version of macOS. (In my case, the file is dated April 30, 2020, which was when I was running Sierra on my previous computer. It got migrated forward and has not been used since then.)

The location of the active preference file for TextEdit is within its sandbox-container:

$ defaults read ~/Library/Containers/com.apple.TextEdit/Data/Library/Preferences/com.apple.TextEdit.plist 
    AVPlayerViewShowsDurationInsteadOfTimeRemainingDefaultsKey = 1;
    NSFontPanelAttributes = "1, 0";
    NSNavLastRootDirectory = "~/Desktop";
    NSNavLastUserSetHideExtensionButtonState = 1;

Which is why it’s better to always use a domain name instead of the path to a file. The domain will go to the right place, which might not be the file you were thinking of. (The man page also says that the tool’s ability to read a specific file may be going away in the future, to be replaced with a different generic plist-access tool).

Of course, for many apps, dumping the entire file is going to be a massive amount of data, and you often don’t care about it all. So you can also choose to specify a single key from a domain. You can also use the read-type command to get the key’s data type. For instance:

$ defaults read-type  com.apple.finder CopyProgressWindowLocation
Type is string

$ defaults read com.apple.finder CopyProgressWindowLocation
{1428, 665}

$ defaults read-type com.apple.finder DesktopViewSettings
Type is dictionary

$ defaults read com.apple.finder DesktopViewSettings
    IconViewSettings =     {
        arrangeBy = grid;
        backgroundColorBlue = 1;
        backgroundColorGreen = 1;
        backgroundColorRed = 1;
        backgroundType = 0;
        gridOffsetX = 0;
        gridOffsetY = 0;
        gridSpacing = 43;
        iconSize = 32;
        labelOnBottom = 1;
        showIconPreview = 1;
        showItemInfo = 0;
        textSize = 10;
        viewOptionsVersion = 1;

Unfortunately, I couldn’t find any obvious way to select a key from within a nested array or dictionary with the defaults command. So you may not be able to select nested keys without reading the entire top-level key and parsing the results.


All this having been said, now I think I can answer the original question about Finder column widths. Unfortunately, it’s not as simple as you’d like.

Underneath the com.apple.finder preference domain, there are several dictionary-keys containing “ViewSettings”, which store the view settings for many special locations, plus a generic one for everything else:

  • ComputerViewSettings
  • DesktopViewSettings
  • FK_DefaultListViewSettings
  • FK_StandardViewSettings
  • iCloudViewSettings
  • MyDocsLibrarySearchViewSettings
  • NetworkViewSettings
  • PackageViewSettings
  • SearchRecentsViewSettings
  • SearchViewSettings
  • StandardViewSettings
  • TrashViewSettings

Within each of these are sub-keys for the different kinds of views. Not all may be present under each - I think it only saves settings when you customize something, falling back to defaults (I think these are FK_DefaultIconViewSettings and FK_DefaultListViewSettings, but I’m not sure of that).

Some of the sub-keys I see for various folder include:

  • ExtendedListViewSettings
  • ExtendedListViewSettingsV2
  • GalleryViewSettings
  • IconViewSettings
  • ListViewSettings

I’m not sure how many of these are used by current versions of the Finder. For instance, there are three ListView settings - I don’t know if they are all used or if only the most recent one (ExtendedListViewSettingsV2, I assume) is used, with the others being read-only for migration purposes.

On my system, ListViewSettings, when present are structured as:

  • calculateAllSizes (boolean) - controls if folder sizes are computed based on the contents
  • columns (dictionary). Contains the per-column configuration, where:
    • The name of the sub-key is the column name (e.g. comments, dateCreated, dateModified, kind, name, etc.) This is probably an internal name used to look up a localized string, to support internationalization.
    • ascending (boolean) determines if this column is sorted ascending or decending
    • index (number) appears to determine the order of the columns appear in a row, with the leftmost column being 0
    • visible (boolean) determines if the column should be shown or hidden
    • width (number) is the the column width. I don’t know what the units are. Probably pixels or points, I would assume.
  • iconSize (number) is the size of an icon in this view
  • showIconPreview (boolean) determines if the icon should show a preview of the file’s data
  • sortColumn (string) is the name of the column that the view should be sorted on
  • textSize (number) is the size (in points, I think) of the text
  • useRelativeDates (boolean) determines how dates are displayed
  • viewOptionsVersion (number) appears to be for internal use, to determine the schema for the data. It’s always 1 on my system.

The ExtendedListViewSettings looks almost identical to ListViewSettings, with the big difference being that columns has changed from a dictionary to an array.:

  • calculateAllSizes (boolean). See above
  • columns (array). One entry for each column. The index field is gone - the position in the array now determines the order of the columns.
    • ascending (boolean). See above
    • identifier (string). The column’s name - almost certainly an internal name used to look up a localized string to present in the UI
    • visible (boolean). See above
    • width (number). See above
  • iconSize (number). See above
  • showIconPreview (boolean). See above
  • sortColumn (string). See above
  • textSize (number). See above
  • useRelativeDates (boolean). See above
  • viewOptionsVersion (number). See above

Finally, the ExtendedListViewSettingsV2 appears to be completely identical to ExtendedListViewSettings. I’m not sure why it exists as a distinct key.


If you want to programmatically change the column widths for a Finder view, what you need to do is:

  • Determine which of the view settings keys (e.g. ComputerViewSettings, DesktopViewSettings, etc.) you want to modify
  • Within that view, look for the three list view settings.
  • Within each list view settings, walk through the columns dictionary/array, to identify each column and write new values to its width field.

You should use a utility that can work with cfprefsd (e.g. the defaults command or Prefs Editor or the CFPrefs API if you’re writing code), so the changes will be properly cached and made available for use.

Once you’ve done this, you may need to restart the Finder, depending on whether or not it re-reads its preferences when they change.


Is that really the question? Or is your script-app not working correctly under the current system and would yo like to reset the Finder prefs again after every restart of Finder?

If you want to edit the prefs file manually since Mojave, it isn’t possible IMHO, because not every app uses a container. I searched for the Finder container (I’m on Mojave), but couldn’t find one. Neither a cfprefs one. In the pre-Mojave systems you could directly edit the prefs file of any app, including Finder. In Mojave one still can access the prefs file in the app containers, and in column view one gets an icon with the readable text of the prefs. Dropping such a prefs file onto Textwrangler (or BBedit I guess) one gets a readable XML parsed file. Dropping it onto TextEdit one gets gibberish, as it doesn’t do structuring. But as I couldn’t find the Finder preference file no answer to your question.
Apple developer has no documentation on cfprefs, and in the Developer forum there are only two questions asked that remotely mention cfprefs.

OTOH, if you want to have your original script to work in a new OS-version, you have to go back to the script file and recompile it under that OS-version, as script apps are dependent on the OS-version they are compiled for. Going from Catalina to Mojave you need to add the terminal-commands to kill and restart cfprefs for Finder to your script to make the changed settings stick.

If I parse the original Finder preferences from ~/user/username/Library/Preferences/com.appl.finder.plist in TextWrangler i get structured output with the same structuring as you described from the Finders preferences containers. So the structuring likely precedes the move to Mojave. Doing a Get Info on the file I notice its last use was yesterday. Could it be that the file is still the active preference file for Finder (so no container)? If so you should be able to find the desired location by looking at the file contents, changing the desired prefs, and doing a Diff on the before and after situations.

That should work. Note, however:

  • You shouldn’t ever assume any particular file. The default system is based on domains (in this case, com.apple.finder). If you want accurate information, you should access them this way.
  • Plist files may be in binary format, which must be read using a compatible application.
  • If you read the preferences using the preference API (e.g. via the defaults command) then it doesn’t matter what format the plist file is using.

So, if you want to read finder preferences, either use a GUI tool like Prefs Editor or type defaults read com.apple.finder in a Terminal window. You can then compare the output from these apps.

1 Like

So I’ve finally managed to pin it down. StandardViewOptions > ColumnViewOptions > ColumnWidth.

Set that to exactly 332 as I want. And indeed, I can see that reflected by querying defaults as well as in the plist file.

Nevertheless, upon Finder relaunch the initial window opens up showing a much skinnier column view. Cannot be more than 80 pixels. Odd. :confused:

Sounds like Finder is caching its own values and is flushing them on a relaunch.

What happens if you force-quit the Finder (select a Finder window and then hold Shift when clicking the Apple menu to see this option)? If this really is a force-quit, then it shouldn’t be able to flush any preferences.

It may also be that the value is stored in more than one place, Finder sees the discrepancy, and reverts the setting back to a default.

My system (Big Sur) doesn’t show the path you’re seeing (StandardViewOptions → ColumnViewOptions → ColumnWidth).

My system shows StandardViewSettings → ListViewSettings (and also ExtendedListViewSettingsV2) → columns → (column-specific entry) → width.

Of course, Apple could have changed all this in Monterey.

It may also be that none of this is used in the way I thought.

Running some tests here, I found that changing the widths didn’t seem to affect anything. The ListViewSettings and ExtendedListViewSettingsV2 need to stay in sync (if they differ, ExtendedListViewSettingsV2 overwrites ListViewSettings after Finder relaunches), but the actual size used in the Finder doesn’t seem to change.

Well, it did once. I changed it from an initial width of 300 to 250 and after a Finder restart, the column got narrower. But any further edits to the preferences did nothing, even though defaults did show that they were saved.

Furthermore, manually resizing the columns didn’t seem to write any changes to the preferences, even after restarting Finder.

So there’s something else going on here. It may be that these preferences are stored in a different domain altogether.

Finder force quit does not change anything about the observed behavior.

Big Sur vs. Monterey differences aside, column width in list view is an entirely different property (lists obviously have columns too). The column width I’m interested in applies to column view, not list view.

I can clearly see that changing this width in Finder affects its defaults value. And I can also clearly see that such changes do get saved. To my surprise even to the plist file—not the case for some other apps (as also Howard Oakley observed when studying differences since cfprefs). The problem as I presently see it is why Finder keeps restoring some other value than what has set and saved. I’d be curious to know where it’s getting that other value from so I can change it there.

Even weirder. If I delete the .DS_Store file for a window, it doesn’t affect the position if I restart the Finder, but it does affect what happens if I simply close/open the window. At least for a short time, until the Finder synchronizes everything.

Whatever’s going on here, I don’t think it will be something that can quickly be fixed by updating a few preferences. These column widths are clearly stored in several places and I think different parts of the Finder’s code are using different locations.

Definitely sounds like bugs, but good luck getting any engineer at Apple to work on it, since it is, ultimately, just a cosmetic bug.

On my Big Sur system, I see nothing at all for Column View in the Finder’s plist and changing the width doesn’t seem to change anything in it.

And nothing I do to change column widths sticks - reopening a window or restarting Finder always goes back to the same (default?) size.

So I’ve got a completely different bug.