File naming conventions: what it does and where it breaks down

A naming convention is the cheapest file organisation there is. It needs no software, no database, and no migration path. It also fails quietly, which is why a folder set up with a careful rule in January is full of exceptions by June. Before deciding whether to keep the rule, tighten it, or replace it with something that runs on its own, it is worth being precise about what a naming convention actually does, what the file system will let it do, and which part of the job it was never going to cover.

A naming convention is two decisions, not one

The first decision is which facts go into the name. The second is what order those facts appear in. Everything after that is formatting.

Only a handful of facts earn a place in a file name. The date the document refers to. The other party. The kind of document. A version or sequence number. A status, if documents move through states. Anything else belongs in the folder path or inside the document, because a name has a hard ceiling and every field spends part of it.

Order matters more than the field list, because the name is also the sort key. A name that opens with the date groups a folder chronologically. A name that opens with the client groups it by client, and the dates scatter inside each group. The same five facts in a different order produce a completely different folder. This is usually decided by accident: somebody names the first file, everyone copies it, and the folder inherits a sort order nobody chose.

A second consequence shows up later. Search matches anywhere in a name, but sorting only reads the front. The field placed first is the only one you can browse. Every other field is reachable only by typing. If the written rule does not say which field is which, the answer will drift from folder to folder.

A test that takes two minutes

Take twenty files out of the folder in question and write down the question asked about them most often. "What did that client send in March" and "what invoices went out in March" are different questions, and they want opposite orders. Whichever gets asked more often goes first.

The date field is where most rules go wrong

Dates are the most common opening field and the easiest to get wrong, because the format that reads well to a person sorts badly on disk.

A date written as 2026-09-12 sorts correctly in every tool and every locale with no special handling, because the fields run from most significant to least. Other orders break in specific ways. 12-09-2026 sorts by day of month, so a year of documents interleaves. Sep-12-2026 sorts alphabetically by month name, which puts April first and September in the middle. And 2026/09/12 cannot be stored in the form it was typed at all.

That last one deserves a concrete answer, because it surprises people who have used the name for years. The POSIX layer of macOS cannot hold a forward slash inside a file name. Finder accepts one anyway and writes a colon in its place. A file that Finder displays as 2026/09/12_invoice.txt is stored as 2026:09:12_invoice.txt, and every script, sync client, and archive tool that reads the real name sees the colon. The substitution is invisible until something other than Finder touches the file.

Dots carry a milder version of the same problem. 2026.09.12 is stored exactly as typed, but tools that treat everything after the final dot as an extension will read a name ending in a bare date as having an extension of .12. Hyphens sidestep both issues, which is the practical reason the hyphenated form became the house default nearly everywhere, rather than any question of taste.

If a time is needed too, the same logic holds. Two digits for the hour, two for the minute, no separator, because the separator that reads best is the colon and the colon is the character that will come back looking like a slash.

Numbers sort only when they are padded

The sequence number is the second field that breaks, and it breaks in a way that hides itself, because two tools on the same machine disagree about the answer.

Finder sorts names the way a person reads them, so 会議資料2 comes before 会議資料10. The command line does not. ls compares character by character, which puts the same six files in this order: 1, 10, 100, 11, 2, 9. Both behaviours are correct for their own context, and neither is going to change.

Zero padding removes the disagreement entirely. With three digits, the same files land in the same order in Finder, in ls, in a listing read by a script, and inside a zip archive. How many digits depends on the ceiling: three covers anything that fits comfortably in one folder, four is right for a sequence that runs daily across a year.

Version numbers have the same defect for the same reason. v2 and v10 sort the way 2 and 10 do. Writing v02 costs one character and ends the problem.

What macOS will actually store

A rule that exceeds what the file system can hold fails at the worst possible moment, which is on the longest and most carefully described name in the folder.

A name on an APFS volume holds 255 units, counted the way the system counts rather than the way a person does. For plain ASCII that is 255 characters. For Japanese text it is also 255 characters, since each one counts as a single unit even though it occupies three bytes on disk. For emoji it is 127, because each one counts as two. Reaching the limit does not truncate the name. The operation fails with "File name too long", and while some tools surface that message, others simply skip the file.

Case is the other boundary. The default macOS startup volume is case insensitive, so Invoice.pdf and invoice.pdf are the same name. A folder cannot hold both, and a process that writes the second over the first gives no warning at all. A convention that separates two documents by capitalisation alone works on a case sensitive Linux server and loses files on a Mac.

One more constraint matters if files ever leave the machine. Older Mac volumes formatted as HFS+ store names in decomposed form, so が is written as か followed by a combining mark. APFS stores what was typed. The two spellings are indistinguishable on screen and compare as different strings, which is how a script that matched every file last week can match nothing once the same files have been copied to an old external drive and back.

Four schemes and what each one costs to keep

Most house rules are a variation on one of these four.

Scheme	Example	Groups by	Cost to maintain
Date first	2026-09-12_acme_invoice_v02.pdf	Time	Low. The date is known the moment the file arrives
Party first	acme_2026-09-12_invoice_v02.pdf	Relationship	Low, while the list of parties stays short and stable
Type first	invoice_acme_2026-09-12_v02.pdf	Document kind	Medium. Everyone has to agree on the type words
Code first	P0417_2026-09-12_invoice.pdf	Project	High. Needs a register mapping codes to projects

The last row is the one that collapses most often, and not because the idea is wrong. It has an external dependency. A code means something only while the register is within reach. When it is not, people guess, and a folder holding two different codes for one project is worse than a folder holding none.

The rows are not mutually exclusive, which is the usual source of confusion when a rule is written down for the first time. A folder tree can group by client while the names inside group by date, and that combination is often the right answer. The mistake is encoding the same fact in both places, so that every file in the acme folder also begins with acme. That costs characters on every name, pushes the useful fields to the right where they are harder to scan, and creates a second copy of a fact that now has to be kept in agreement with the first one.

When more than one person writes into the folder

A rule that one person follows is a habit. A rule that several people follow is an agreement, and agreements need a visible reference or they decay toward whatever the most recent example looked like. The cheapest version of that reference is a file in the folder itself, named so that it sorts to the top, containing the rule in one line and two correct examples. It costs nothing and it survives staff changes, which a rule living in somebody's head does not.

The second thing worth agreeing on is what to do with a file that arrives outside the rule. Two answers work. Rename it on arrival, or leave it alone and accept that the folder holds two populations. What does not work is renaming some of them, because then neither a browse nor a search returns a complete set, and nobody can tell which failure they are looking at.

The part a naming convention was never going to cover

A naming convention is not a property of a folder. It is a property of the instant a file arrives, and there are only a few such instants.

Files a person saves deliberately follow the rule, because a person is standing there thinking about the name. Almost nothing else does. A browser download keeps whatever the server sent. A scanner writes its own counter. A camera writes DSC and four digits. An email attachment arrives under the sender's convention, if the sender has one. A screenshot gets a timestamp in the system format, which is not the format in the rule. In most working folders the files that follow the house rule are a minority, and they were the files least likely to get lost in the first place.

That is the honest limit. The rule governs what gets typed, and most file names are not typed. From here the rule can be extended in two directions. Either the capture points get fixed one at a time, changing the scanner template and the download destination so that fewer files arrive unnamed, or a bulk rename step is added after the fact. The built-in tools cover the second case: Finder's Rename Items does replace, add, and format with an index, counter, or date, and Shortcuts and the shell handle the cases that need a condition rather than a fixed pattern. A file manager with a built-in terminal shortens that loop by keeping the listing and the command on one screen, so a rename that has to be verified against the folder does not mean moving between two windows. Whether any of that is worth paying for is a separate question, and the Pricing page is where it gets compared against what macOS already includes.

What to change first

Write the rule for one folder in a single line, fields in order, padding width included, and put it where the people using that folder will see it. Then look at the last twenty files that landed there and count how many were named by a person rather than by a device. If it is fewer than half, the next change belongs at the capture point rather than in the wording of the rule, and a Finder replacement that can rename in place while the folder is still open is the cheaper of the two remaining moves. Atriens is one of them.