← NotesFiles & naming4 min read

Naming conventions that survive five years

Most file naming schemes work for a month and fall apart when the project grows, the team changes or the files move to another system. Here are the rules that hold up, and a template you can adapt.

Every folder of work starts with sensible names. Then Report final.docx gains a sibling called Report final v2.docx, then Report FINAL use this one.docx, and five years later nobody — including you — can tell which is which.

A naming convention is a small set of rules decided in advance. The good ones share a few properties: they sort correctly, they survive being moved between systems, and someone new can understand them without asking.

Rule 1: Dates as YYYY-MM-DD, at the front

2026-10-02 sorts correctly as text. 02-10-2026 and 10-02-2026 do not — and they are ambiguous between countries. 2 Oct 2026 sorts alphabetically by day number.

Put the date first when chronology matters — meeting notes, invoices, photographs, reports — so the folder sorts itself in time order. This format is the international standard ISO 8601, and nearly every system understands it.

If you need the time too: 2026-10-02_1430. Avoid colons, which are problematic on several systems.

Rule 2: Pad numbers

File 1, File 2 … File 10 sorts as 1, 10, 2 on many systems. File 01, File 02 … File 10 sorts correctly everywhere.

Pad to the largest number you expect, plus one digit for safety. Three digits (001) covers most projects.

Rule 3: Versions are numbers, not adjectives

final, latest, new, use this all eventually become false. A version number never does.

  • v01, v02, v03 for drafts.
  • Keep the date in the name as well if versions are spread over time.
  • For the version sent to someone: the version number, plus a note in a separate file or the email, not SENT in the filename.

If you need to mark approval, move the approved file to an Approved folder rather than renaming it.

Rule 4: A fixed order of elements

Decide the parts and their order once:

date_project_subject_version.ext

2026-10-02_ACME_brand-guidelines_v03.pdf

Every file in the project follows the same order. That lets you scan a folder, sort it, and search it predictably — "everything for ACME" is everything with _ACME_ in position two.

Use a short project code rather than the full client or project name. Codes do not change when the client rebrands.

Rule 5: Safe characters only

Files move between Macs, Windows machines, servers, cloud drives and email. Characters that are fine on one can break on another:

  • Avoid: / \ : * ? " < > | — illegal or special on at least one major system.
  • Avoid: leading or trailing spaces and full stops.
  • Be careful with: accented and non-Latin characters. They usually work, but some older systems, zip tools and web uploads still mishandle them. For shared or long-lived archives, plain ASCII is safest.
  • Spaces: fine on modern desktops, awkward in web addresses and command lines. Hyphens or underscores avoid the question.

A common convention: underscores between elements, hyphens within them. 2026-10-02_ACME_brand-guidelines_v03 — each element is easy to pick out, and the whole name has no spaces.

Rule 6: Consistent case

Pick one: all lowercase, or capitalised words. Mixing produces names that look like duplicates and are not: Brand-Guidelines and brand-guidelines are the same file on a Mac by default, and different files on Linux.

Lowercase is the simplest rule to follow and never ambiguous.

Rule 7: Keep names reasonably short

Deep folder structures plus long names hit path length limits on some systems, particularly Windows and some sync tools. Aim for names under about 60 characters and let the folder carry context, not the filename.

Rule 8: Write it down

A convention that lives in one person's head dies when they leave. Put a short README in the project's top folder with the pattern and two examples. It takes five minutes and is the difference between a convention and a habit.

A template to adapt

YYYY-MM-DD_PROJECT_subject-in-words_v01.ext

Examples:

2026-10-02_ACME_kickoff-notes_v01.md
2026-10-02_ACME_brand-guidelines_v03.pdf
2026-10-15_ACME_invoice-0042.pdf
2026-09-14_ACME_site-visit_001.jpg

Drop the elements you do not need. Photographs might be date_event_counter; invoices date_client_invoice-number.

Applying it to what already exists

A convention is easy to apply to new files and tedious to apply to old ones. The usual approach:

  1. Apply it to all new files immediately.
  2. Rename active folders when you next work in them.
  3. Leave archived material alone unless you need to search it — or rename it in bulk.

Where RenameDeck fits

RenameDeck is a batch renamer for Mac built for step three.

Template rules build names from parts in a fixed order. Date rules can use file-system dates or dates from EXIF and other metadata, formatted as YYYY-MM-DD. Sequence, zero-pad and renumber rules handle padding. Case and whitespace rules standardise the rest, and replace rules with literal, wildcard or regular-expression filters clean up old habits like final and use this.

Rules stack into recipes you save and reuse, and a frozen recipe can be assigned to a trusted folder so new files are renamed as they arrive. Every proposed name is shown before anything changes, with invalid names and collisions flagged; RenameDeck never overwrites an existing file, and journaled history supports undo.

It is sandboxed with no network entitlement, account, analytics or tracking, and requires macOS 14 or later.

Keep reading