File naming conventions: how to decide what you need

Choosing a document naming convention stalls for a predictable reason. Every format on offer works somewhere, so comparing formats produces no answer. The decision only becomes tractable when the conditions come first: who reads the name, how many files pass through per day, and whether the name ever leaves the Mac it was typed on. Settle those and the format falls out of them, usually in under an hour.

Four different readers want different things

A filename gets read by four parties, and they do not want the same string.

• A person wants the left edge of the list to explain the file without opening it.
• The Finder only compares text. A date in the middle of a name does not produce a chronological list.
• A shell or a script wants consistent delimiters. One file with a different shape stops the loop.
• An outside system has its own rules already, in the form of submission requirements, attachment limits and character restrictions.

Most stalled conventions are the result of optimising for the first reader alone. A name like Invoice for A Corp (January 2026).pdf reads beautifully and sorts by nothing useful, and every shell command that touches it needs quoting. The reverse failure is just as common: 20260102_ac_inv_01.pdf is perfectly machine friendly and unreadable six months later by the person who created it.

Ranking the four readers is the first real decision. A folder of documents that never meets a terminal and never gets shared has no reason to accept machine oriented constraints. A folder that a monthly script walks through has every reason to accept them.

Four decisions, and everything else can wait

The reason naming projects stall is a sense that there is too much to settle. There are four items that genuinely have to be settled first.

• The date: whether one appears, in which format, and what event it refers to.
• The separators: whether spaces are allowed, and how hyphens and underscores divide things.
• The field order: which of date, counterparty, document type and subject comes first.
• The version scheme: sequential numbers, dates, or no version in the name at all.

Capitalisation, language and whether extensions are visible can all be decided later without disturbing existing files. The four above cannot. Changing field order after the fact moves every file to a different position in every list, which means a full rename, which in turn means chasing down every link, shared URL and hard coded path that pointed at the old names. Deciding four things in the first week and leaving the rest open is the cheaper order.

Date formats compared on the three things that matter

A leading date is common because of how sorting works, not because of fashion. Lists are ordered by comparing text, so a name beginning with 20260102 sorts chronologically for free.

Format	Sorts chronologically	Easy to parse	Reads naturally
20260102	Yes	Yes, fixed width	Moderate
2026-01-02	Yes	Yes, delimited	Yes
2026年1月2日	No, single digit months break it	No	Yes for Japanese readers
Jan-2-2026	No, alphabetical by month	No	Yes for English readers
R8.1.2	Breaks at each era change	No	Only in specific contexts

The top two rows are the practical choices. Eight digits stay short and introduce no separator. The hyphenated form is easier to read and lets a script take the date portion without counting characters. Sorting behaves identically either way, so the decision rests on whether people or scripts read the name more often.

One question gets skipped and causes trouble later: what the date refers to. An invoice dated 20260131 might be the day it was produced or the last day of the period it covers. Minutes might carry the meeting date or the date the notes were tidied. Write one line per document type fixing the meaning, because a month end reconciliation is where the ambiguity surfaces, and by then there are hundreds of files with two meanings mixed together.

Separators depend on whether a shell is involved

Spaces in filenames look like a matter of taste until a command line enters the picture. Apple's own guidance on specifying files and folders in Terminal recommends sticking to letters, numbers, periods and underscores, and notes that paths containing spaces should be wrapped in quotes.

Quoting works, so spaces are not forbidden. The cost is that every hand typed command needs it, and forgetting once points the command at something else. For anyone running commands daily, a space free name removes that class of mistake permanently.

The arrangement that survives contact with both readers uses two levels. Hyphens join words inside a single field, underscores divide the fields from each other. In 20260102_a-corp_invoice_01.pdf, splitting on underscores returns exactly four fields, and a hyphenated company name does not break the split. Using underscores for both levels throws that structure away, which matters as soon as anything needs to extract the counterparty automatically.

Field order is the decision that cannot be revisited cheaply

Once the fields exist, their order determines what the list looks like when a folder is opened, and that is the part people notice every day.

Leading with the date produces a chronological list and groups nothing. It suits folders where recency is the main question: downloads, correspondence, scans waiting to be filed. Leading with the counterparty groups everything for one client together and scatters the timeline. It suits a folder that already contains one project's whole history. Leading with the document type is rarely right at the top level, because a folder of every invoice ever issued, in no particular order, answers no question anyone actually asks.

A useful way to choose is to write down the question asked most often when that folder is opened. "What arrived recently" points to a date first. "What has been sent to this client" points to the counterparty first. Where both questions come up, the date usually wins, because client grouping can be recovered with a search while chronology cannot be recovered from a scattered list without sorting by a date that may have been rewritten.

What makes this decision expensive is that reversing it moves every file to a different row in every list, and anything referencing the old names has to be found and updated. Unlike capitalisation or language, there is no way to change field order for new files only without ending up with two conventions living in one folder, which is worse than either convention alone.

Limits worth knowing before the rule is written

macOS accepts a wide range of characters, and accepting is not the same as being safe.

Three restrictions are hard. A colon cannot be used. A name cannot begin with a period. Some applications will not accept a forward slash. Apple documents these under renaming files, folders and disks.

Length has a limit too, and it is easy to measure. On APFS, a name of 255 characters is created without complaint and a name of 256 characters fails outright. The count is by character rather than by byte, so a Japanese title hits the same 255 as an English one. Any rule that copies a document subject into the filename needs a cap on how much of the subject is copied.

Composition is the restriction that surprises people working in Japanese. A character such as ば can be written as one code point or as two, and a test on APFS shows the system storing whichever form was typed while still opening the file when the other form is used. Nothing looks wrong locally. The mismatch appears when the name travels to a system that compares the two forms as different strings, and a reconciliation that should match silently does not. How well a tool handles names across scripts and locales is a real difference between file managers, and the languages page sets out the range covered.

Versioning is where conventions die

Rules collapse in the final week before a deadline, and the collapse is nearly always about versions rather than discipline. Once final, final2 and final_approved appear in a folder, the rule never recovers.

There are three workable schemes. Sequential numbers, dates, or no version in the name at all.

Sequential numbers need a fixed width. A run from v1 to v10 sorts v10 ahead of v2, because text comparison puts 1 before 2. Two digits from the start avoids it. Dates as versions need a rule for the second revision on the same day, usually a small counter appended to the date.

The related decision is whether status belongs in the name. Adding _approved changes the filename at the exact moment other documents start linking to it, and those links break silently. A reasonable split is that files referenced by anything else keep fixed names and express status through folder position, while private working files can carry status in the name at little risk.

Volume decides whether the rule survives

The quality of a convention matters less than the number of files per day passing through it. Up to a handful per day, names can be typed by hand at save time. Past a few dozen, hand typing stops happening, and the rule quietly dies regardless of how good it was.

The practical move is to count the entry points instead of the files. There are usually about four: downloads, scanners and copiers, cameras and screenshots, and shared folders or email attachments. For each one, decide whether the name is set at the point of arrival or fixed afterwards. Scanners that accept a naming template are best configured at the device, because nothing then depends on anyone remembering.

One more thing belongs in the design rather than in the discipline: a place for documents that fit no pattern. Every set of rules produces exceptions, and forcing them into the scheme is what makes a scheme complicated enough to abandon. A single folder where names are not checked absorbs them, and the convention then only has to cover what did not land there.

For the rest, the Finder's bulk rename can add a counter, an index or a date around an existing name, and that covers a surprising amount. Where it does not, a command or a dedicated tool takes over, and features is the place to check what is built in before assuming manual work is necessary.

What to change first

Write down three finished filenames for the document types actually in use, not a paragraph of rules, because people copy examples and skip prose. Then set up one check that lists names not matching the pattern and run it once a month, treating every recurring exception as evidence the rule needs adjusting rather than the person does. Seeing the list and running the check in the same window is the part Atriens is built around, and it is also the part that decides whether the convention is still alive in six months.