File naming conventions that hold up a year later: rules you can keep

Most file naming conventions are written once, followed for three weeks, and then quietly abandoned. The document survives in a shared folder; the files stop matching it. What went wrong is rarely the rule itself. It is that the rule required a decision at the moment of saving, and the moment of saving is when attention is lowest.

A convention that holds has a different shape from one that reads well. It has fewer fields, the fields are answerable without thinking, and something other than memory puts them in place. This covers which fields earn their keep, which characters and lengths genuinely break things across systems, and how to make the rule enforce itself.

Why conventions get abandoned

Three failure patterns account for nearly all of it.

The convention has too many fields. A name specified as ProjectCode_ClientName_DocumentType_Author_Date_Version_Status requires seven decisions. Two of them, author and status, change over the life of the file, which means the name has to be edited later or it becomes wrong. A name that goes stale is worse than no convention, because it cannot be trusted and therefore cannot be searched.

The fields are not answerable at save time. Document type sounds obvious until the file is a spreadsheet used as a report. Project code sounds obvious until the work predates the code being assigned. Any field that needs a lookup or a judgement call is a field that gets skipped under pressure.

The convention duplicates the folder path. A file at Clients/Acme/2026/Invoices/ named Acme_2026_Invoice_003.pdf states the same three facts twice. Every save requires re-entering information the path already carries, and the two copies drift apart the first time a folder is reorganised.

The corrective is to cut fields until every remaining one is answerable in under a second and is not already in the path. In practice that leaves two or three.

Design from retrieval, not from filing

The useful question is not how to describe a file. It is how the file will be found again in eleven months.

There are only three retrieval routes on a Mac, and they want different things from a name. Sorting a folder by name wants a fixed-width field at the front, so that alphabetical order equals meaningful order. Spotlight wants distinctive words anywhere in the name, because it does not care about position. Shell globbing wants predictable separators and no spaces, so that *.pdf and 2026-09-* match what they look like they should match.

A name that serves all three has one sortable field at the front and distinctive words after it. That is the whole design. Everything else is decoration.

Which route dominates is worth deciding explicitly, because it settles arguments. A folder of scanned receipts is browsed by sorting, so the date goes first. A library of reference documents is found by searching, so the title carries the weight and the date can go at the end. A directory of build artefacts is matched by scripts, so separators matter more than readability.

The date field, and why its format is not a style choice

Putting a date at the front of a filename is common advice. The format is where it goes wrong, and the difference is not cosmetic.

Format	Sorts correctly by name	Ambiguous across regions	Length
2026-09-26	Yes	No	10 characters
20260926	Yes	No	8 characters
26-09-2026	No	Yes	10 characters
Sept 26 2026	No	No	12 characters
9-26-26	No	Yes	7 characters

Only the first two sort chronologically when a folder is sorted by name, because they put the most significant component first and pad every component to a fixed width. That property is what makes the field worth having at all. 26-09-2026 groups every 26th of the month together, which is never what anyone wants.

Between the two workable forms, the hyphenated one is more readable and the compact one is shorter. Either is fine as long as it is one of them and not both. Mixing 2026-09-26 and 20260926 in the same folder breaks sorting exactly as badly as using a regional format, because the two forms do not interleave.

Zero padding applies to every numeric field, not just dates. A sequence that runs 1, 2, ... 10, 11 sorts as 1, 10, 11, 2. Padding to 001 fixes it, and three digits covers most cases without looking absurd.

Characters that actually break things

Most character advice is inherited folklore. The real constraints are documented and narrower than the folklore suggests.

Microsoft's own naming documentation lists the characters that cannot appear in a Windows filename: <, >, :, ", /, \, |, ?, and *. It also lists reserved device names that cannot be used as a filename at all, including CON, PRN, AUX, NUL, COM1 through COM9, and LPT1 through LPT9, and notes that these remain reserved even with an extension added. And it states plainly that a name should not end with a space or a period, because the Windows shell does not support it even where the filesystem does.

Two of those matter specifically on a Mac. The colon is legal in macOS filenames and appears constantly in names typed by people, usually in a time or a title. Those files cannot be copied to a Windows machine or placed in a zip archive destined for one without being renamed. The forward slash is the inverse case: it is the path separator on macOS and cannot be used, but the colon historically served that role, which is why the Finder still quietly swaps the two in some contexts.

Spaces are legal everywhere and break nothing at the filesystem level. They cost something only at the shell, where every reference needs quoting, and in URLs, where they become %20. For files that scripts touch, underscores or hyphens are less work. For files that only people touch, spaces are fine and more readable. Pretending spaces are dangerous leads to conventions nobody wants to follow.

Non-ASCII characters are safe on APFS and on modern Windows filesystems, which store names in Unicode. They stop being safe at two specific boundaries: zip archives, where the bundled extractor on macOS has no encoding option and produces garbled names, and older web servers. A name that stays inside a Mac and a Git repository can use any script it likes.

The limits that bite

Two hard numbers are worth knowing, and a third is worth knowing as a trap.

A single filename component cannot exceed 255 characters on macOS. The limit is per component, not per path, and attempting to create a longer one fails immediately with a file name too long error. NTFS, exFAT and FAT32 share the same 255-character limit for names.

Total path length is where the systems diverge. Those filesystems allow paths up to 32,760 characters, but the Windows API enforced a much lower limit: MAX_PATH, defined as 260 characters, in editions before Windows 10 version 1607. Later versions can lift it, but only after a registry or Group Policy change. The practical consequence is that a deeply nested folder tree with descriptive names at every level travels badly. A path that works on a Mac can be unopenable on a colleague's Windows machine, and the error surfaces during a copy rather than at creation.

The trap is case. APFS is case-insensitive by default, which can be confirmed in a second: create Report.txt and then ask for report.txt, and the same file comes back. Any convention that relies on case to distinguish two files works on a case-sensitive Linux server and fails on the Mac that syncs from it, silently, by overwriting. Case is fine for readability. It is not a field.

Version and status fields, and where they go wrong

Version numbers in filenames are the most-attempted and least-successful field.

The failure is predictable: report_v2_final.docx is followed by report_v2_final_FINAL.docx and then report_v2_final_v3.docx. The cause is that "final" is a status, statuses change, and a name cannot be edited without breaking every link to it. Any field describing the current state of a file will eventually contradict the file.

There are two arrangements that hold. The first is to keep versions out of names entirely and let a version control system or the Mac's own file versions hold them. This is correct for anything textual and anything in a repository. The second, for cases where distinct versions genuinely need to coexist as separate files, is to use the date as the version: 2026-09-26_pricing-model.xlsx next to 2026-10-03_pricing-model.xlsx. The date never needs editing, it sorts correctly, and the most recent one is unambiguous.

What does not work is a status word in the middle of the name. If a status has to be visible, it belongs in a Finder tag, which can be changed without touching the name, or in a folder, which moves the file rather than renaming it. Tags carry a caveat: they are stored as extended attributes, and exFAT cannot hold extended attributes at all, so a tag does not survive a trip through a shared external drive.

Enforce it instead of remembering it

A convention followed by hand decays at a predictable rate. The fix is to move the work off the person saving the file.

Three mechanisms cover most of it. Batch renaming handles the backlog: the Finder's own rename action on a multiple selection can insert a format and a sequence number, and rename or a short shell loop handles patterns it cannot express. A template file with the naming pattern already in place means the fields are edited rather than typed. And a folder action or a scheduled script can normalise names on arrival, which is the only approach that works for files other people send.

The shell version is short enough to keep:

for f in *.pdf; do
  d=$(stat -f %SB -t %Y-%m-%d "$f")
  mv -n "$f" "${d}_${f}"
done

That prefixes each file with its own creation date, using -n so nothing is overwritten. It is not the convention itself, but it demonstrates the principle: the date field is derivable, so nobody should be typing it.

The reason this step is usually skipped is friction. Writing the loop means leaving the folder view, finding the path, switching to a terminal, and pasting it in, which is enough work that the rename gets done by hand instead. A file manager that keeps the folder view and the shell in the same window removes that gap, and the automation starts getting written, which is a large part of what Compared with other file managers is weighing. Conventions with non-Latin fields have a further consideration, which Languages addresses.

What to change first

Cut the convention down to two fields: a zero-padded date in YYYY-MM-DD form at the front, and a short descriptive phrase after it. Drop author, status and version from names entirely and let tags, folders or version control carry them. Then write one rename loop for the folder with the worst backlog, because a convention applied to new files while old files stay inconsistent is a convention that still cannot be searched. If the loop keeps not getting written because the folder and the shell are in different windows, that is the thing to change, and Atriens exists for that arrangement.