How deep should a folder structure on a Mac go?

Deep enough that each level answers one question, which in practice is three levels for most work. Depth is paid on every retrieval and breadth is paid once, when deciding where something goes. If a fourth level is needed, it is usually a sign that two different sorting axes have been combined into one tree.

Should folders be named in English even on a Japanese system?

For anything a shell, a script, or an agent will touch, English names without spaces are easier to work with, because they can be typed without switching input modes and quoted without care. For folders that only ever get clicked, the name should be whatever is fastest to recognise. Mixing both is fine as long as the boundary is deliberate.

Why do some folders open as a single document instead of showing their contents?

They are bundles, which macOS presents as one object even though they are directories. Applications, rich text documents with attachments, and photo libraries are the common examples. Right clicking and choosing Show Package Contents opens the directory, and the shell shows the same contents without any special step.

Does moving files around break Spotlight or the recent items list?

Spotlight follows the move and reindexes, usually within a short time, so search continues to work. Aliases follow the move as well, since they track identity rather than path. What breaks is anything that stored a plain path: symbolic links, saved shell commands, and references inside project files that were written by hand.

Folder structure on Mac: the parts you cannot choose

Most advice about folder structure treats the question as a taxonomy problem: pick an axis, decide between client and project and year, limit the depth. That advice is not wrong, and it is also not where structures fail. They fail because a folder tree is read by three different things that disagree about what a name is, what a folder is, and where a file actually lives. Finder reads it one way. The shell reads it another way. A sync client reads it a third way. A structure that only works in the first of those three is the one that quietly stops being used after a month.

What follows is the part of the question that is not a matter of taste: the folders macOS has already decided, the properties a structure needs in order to survive all three readers, and a short test to run on a proposed structure before moving anything.

The folders macOS decided before you did

The home folder arrives with a fixed set: Desktop, Documents, Downloads, Movies, Music, Pictures, Public, and a Library folder that is hidden from view. Those are not suggestions. Several system behaviours are bound to them, so a structure that ignores them ends up fighting the system rather than the mess.

Downloads is the clearest case. It is an arrival point rather than a location, because every browser and messaging client writes there by default. Treating it as a folder in the structure guarantees that the structure fills with things nobody filed. The same applies to the desktop, which is a folder like any other and is therefore an appealing place to leave things, with the difference that its contents are drawn on screen and so it is never out of sight.

The Library folder inside the home folder is where applications keep state that belongs to them rather than to a person. Sandboxed applications go further and keep their data inside a container of their own, at a path that includes the application identifier. This produces a common surprise: a document visible inside an app is not necessarily anywhere in the visible structure, and it may not be where a backup rule expects it.

Movies, Music, and Pictures carry a different kind of claim. Media applications expect to manage their own libraries inside them, and those libraries are single objects from the outside. Filing loose video files next to a managed library is legal and produces a folder where half the contents are owned by an application and half are not, which is the sort of ambiguity that makes a structure feel unreliable without anyone being able to say why.

The last constraint is optional and easily turned on by accident. macOS can move Desktop and Documents into iCloud Drive, after which those two folders are managed by sync and can be evicted locally when space is short. A structure whose top level lives inside a folder that another system can move is not a structure that is under one person's control. Knowing whether that option is on is a prerequisite to designing anything above it.

Sorting is by name, so the structure lives in the names

A folder view is sorted, and the sort is almost always by name. This means the ordering is not a separate feature to configure. It is an output of the naming scheme, and a naming scheme is therefore part of the structure rather than a detail applied afterwards.

Dates are the strongest example. A date written as 2026-09-04 sorts chronologically as text, which is the only reason a folder of dated items ever looks tidy. A date written as 4 Sep 2026 or 09042026 does not, and no amount of hierarchy fixes it. Putting the date first in the name also means a folder can hold two years of material and still be readable, which removes the temptation to create a year level in the tree.

Numbers behave the same way. 10 sorts before 2 unless the numbers are padded, so a set of numbered stages needs a fixed width from the start. Renaming later is possible, using the Finder rename panel that offers replacement, added text, and a format with a counter, but the links and references that already point at the old names are not renamed with them.

There is a second reason names carry the structure, and it only appears once the shell is involved. Tab completion resolves on unique prefixes, so two sibling folders that share their first several characters cost a keystroke every time either one is typed. Naming siblings so that they diverge early is invisible in a folder window and quietly valuable everywhere else.

Some folders are files, and some files are folders

macOS presents certain folders as if they were single documents. An application, a rich text document with images, and a photo library are all directories that the Finder opens as one object, with the contents reachable only through Show Package Contents. The shell sees them as ordinary directories with hundreds or thousands of entries inside.

This matters for structure in three ways. Anything filed inside such a bundle is invisible in the folder view, so it will not be found by browsing. A sync client counts every internal file separately, which is why moving one photo library into a synced folder can produce an alarming file count and a very long first upload. And a backup rule written in terms of file counts or sizes behaves unexpectedly when a single visible item expands into a directory tree.

The practical rule is short: never place working material inside a bundle, and never build a structure whose depth was measured in the Finder without checking what the bundles inside it contain. The visible tree and the actual tree are different documents.

Aliases and symbolic links build different structures

Both give a folder a second location, and they are not interchangeable.

A Finder alias records the identity of its target, so it survives the target being moved or renamed. It is also a Finder concept. The shell cannot follow it, and neither can most command line tools, so a structure held together by aliases works when browsing and collapses the moment a script walks the same tree.

A symbolic link, created with ln -s, is part of the file system, so both Finder and the shell resolve it. Its weakness is the mirror image: it stores a path rather than an identity, so moving or renaming the target leaves the link pointing at nothing.

	Survives the target moving	Visible to the shell
Finder alias	Yes	No
Symbolic link	No	Yes

The choice follows from who reads the structure. A shortcut in a sidebar for a person to click can be an alias. A path that a build step, a backup rule, or a coding agent will traverse has to be a symbolic link or a real location.

Where a structure quietly breaks

Four properties of the file system defeat structures that looked reasonable on paper.

Names are compared without regard to case by default, so Invoices and invoices are the same folder. A structure that distinguishes them survives on a Mac only by luck, and breaks the moment it reaches a case sensitive system such as a Linux server or a repository checked out elsewhere.

Accented and marked characters can be written in two ways, as a single character or as a base character followed by a mark. APFS treats both forms as the same name, which is convenient in the folder view and confusing at the boundary, because a search or a script comparing raw bytes may see them as different strings.

A colon cannot appear in a name at all, a name cannot begin with a period, and the limit is 255 characters. Names close to that limit are rare in a folder view and common in generated exports, where a long title and a timestamp are concatenated.

Spaces are legal and cost nothing in the Finder, while in the shell every unquoted space splits a path into two arguments. A structure full of spaces works perfectly until the first command is written against it, and then it produces errors that look like the command is wrong.

Sync adds a fifth failure that belongs in the same list. A synced folder can contain items that are present in the listing but not on the disk, downloaded only when opened. In a folder window they look identical to local files. To a script that opens them they are either slow or absent, depending on the client. Any structure whose working directories sit inside a synced tree needs that behaviour checked before it is trusted, not after a build fails at an awkward moment.

A test to run before moving anything

Three checks catch most of the problems above, and they take a few minutes.

Type the path. Open Go to Folder with Command plus Shift plus G and type the intended path from memory. If it cannot be typed without checking, it cannot be dictated to anyone else either, including a tool that takes a path as input.

Walk it with a command. List the tree from the shell and compare it against the folder view. Any difference between the two views is a bundle, an alias, or a sync placeholder, and each of those is a future surprise.

Count the hops. Reaching a current working item should take two steps from an obvious starting point. If it takes four, the depth was chosen for filing rather than for retrieval, and filing happens once while retrieval happens daily.

Deciding what to do about it

A structure that passes those checks is stable, and the remaining cost moves elsewhere. It shows up as the trip between the folder that holds the material and the shell that operates on it, because a good structure makes paths longer and more descriptive, and long descriptive paths are exactly what nobody wants to retype.

That is the point where the shape of the tool starts to matter more than the shape of the tree. Keeping the folder view and a terminal on the same current directory removes the retyping entirely, and what that covers is described under Features. How that arrangement differs from the two pane managers usually recommended for file organisation is set out on the Compared with other file managers page. Naming conventions in mixed language teams have their own failure mode, since a structure written partly in one script and partly in another sorts unpredictably, and the language handling is listed under Languages. Questions that come up before committing to a change are collected in the FAQ.

What to change first

Check one thing before redesigning anything: whether Desktop and Documents are currently being synced to iCloud Drive, because that answer decides where the top of the structure can safely sit. Then apply date first naming to the one folder that gets the most new material, and leave the rest alone until that folder has held its shape for a month. If the friction that remains is typing paths into a shell, the fix is a window where the folder view and the terminal share a location, such as Atriens.