A photo file naming system that sorts correctly

Almost every naming system a photographer invents works fine for about eight months, then quietly stops sorting in the right order and nobody notices until they are looking for a job from two years ago. The fix is not discipline. It is picking a format that a computer sorts correctly by accident. Here is that format, written out, with the mistakes that break it.

A file name is a sort key, not a description

When you open a folder, a backup log, an FTP listing or a gallery upload queue, the software puts your files in order by comparing their names one character at a time, left to right. It looks at the first character of one name and the first character of the next. If those match it moves to the second character, and so on. It does not know that part of the name is a date, or a client, or a frame number. It is reading text.

Everything below comes from that single fact. If you want folders that fall into the right order without being told, you have to arrange the information so that a plain left to right text comparison happens to get it right. Get that wrong at the start and no amount of care later fixes it, because you end up fighting the sort on every job you shoot from then on.

So the name has three jobs, in this order: put the file in time order, say which job it belongs to, and say which frame it is. Three jobs, three fields, in that sequence. Anything else in a file name is decoration, and decoration is what makes systems collapse.

Why the date has to be year, month, day

Write the date year first, then month, then day, each padded to its full width: 20260314. This is not a house style preference. It is the only ordering that sorts correctly, and the reason is the one from the last section. A text sort weighs the leftmost characters most heavily, so for character order to match time order, the most significant unit of time has to sit on the left. Year, then month, then day. That is exactly what the international date standard, ISO 8601, specifies, and it is why nearly every log file in the world timestamps that way.

It is easier to see than to argue about. Take three real jobs: an Alvarez wedding on March 14, 2026, a Chen portrait session on November 2, 2026, and a Bell wedding on January 5, 2027. Here is where each one lands in an alphabetical folder listing under each date format.

The two wrong columns are not wrong because of anything you did. They are wrong because the most significant number is not on the left. And notice that both broken formats look completely fine when you have four jobs. They break silently, at volume, years later.

You can write the date as 20260314 or 2026-03-14. Both sort identically and correctly. I prefer no separators inside the date so the whole date reads as one solid token and the underscores stay meaningful as field dividers. Pick one and never mix them.

The convention, field by field

Here is the whole system, and it really is this short:

YYYYMMDD_client_shoottype_####.ext

Which gives you names like these:

• 20260314_alvarez_wedding_0001.cr3, the first frame of the day
• 20260314_alvarez_wedding_2847.cr3, the last frame of the same day
• 20260602_chen_newborn_0044.arw
• 20260919_westbrook_headshots_0112.nef

The date field

Use the day the frame was shot, not the day you ingested it. It matters for anything that runs past midnight and for multi day events, where using the shoot date keeps a three day conference in the order it actually happened rather than collapsing it into one lump.

The client field

One token, lowercase, surname or business name only. No first names, no ampersands, no "and". The Alvarez wedding is alvarez, not maria-and-tom-alvarez. If you shoot two families with the same surname, add one initial: smith-j and smith-r. You do not need to worry about shooting the same client twice, because the date already separates those jobs.

The shoot type field

This one has a rule that people skip and then regret: the value must come from a short fixed list you write down once. Mine is wedding, engagement, portrait, family, newborn, headshots, corporate, event, product, property, personal. Eleven words. The fixed list is the entire point, because the moment you type weddingday instead of wedding on a tired Sunday, every search you run afterward is quietly incomplete.

The second shooter case

If someone else's frames land in the same job, give them their own field before the sequence: 20260314_alvarez_wedding_b_0001.cr3. You keep both cameras in one job folder, in one time order, while still being able to see at a glance whose frame is whose, which matters when you are checking coverage or paying someone. We go deeper on that handover in our guide to setting standards for second shooter photos.

The number at the end, and why it needs zeros

Four digits, starting at 0001, renumbered across the whole job rather than carried over from the camera. Two bodies produce two sets of camera numbers that collide, and a card that rolls over from 9999 back to 0001 mid reception will do it at the worst possible moment. Renumbering at ingest solves both in one pass.

The zeros are not decoration. Without them, a folder of frames numbered 1 upward sorts as 1, then 10, then 100, then 1000, then 1001, and frame number 2 turns up more than a thousand rows further down the list. With four digits, 0001 through 0002 through 0010 through 0100 through 1000 sit in the order you expect, because every number now occupies the same number of character slots and the comparison stays honest.

Four digits covers 9,999 frames, which is comfortably more than the 2,000 to 4,000 RAW frames a full wedding day typically produces. If you shoot multi day events with two bodies and genuinely pass ten thousand frames in one job, use five digits for everything. Consistency beats efficiency here. Never mix widths inside a library.

Eight things that quietly break sorting

Every one of these looks harmless on the day you do it.

1. Month names. 2026-mar-14 sorts alphabetically: April, August, December, February, January, July. Never put a word where a number belongs.
2. Client name first. alvarez_20260314 throws away chronology completely. Your library becomes an address book you have to already know the answer to before you can search it.
3. Unpadded numbers. Covered above, and the single most common one.
4. Spaces. They turn into %20 in gallery URLs, they need quoting on any command line, and some sync tools silently trim a trailing one so two names that look identical are not. Underscores between fields, hyphens inside a field.
5. Mixed case. In a plain text sort, every uppercase letter comes before every lowercase one, so Alvarez and alvarez land in different halves of the same folder. Lowercase everything, with no exceptions, forever.
6. Punctuation the file system cares about. The characters / \ : * ? " < > | are illegal or reserved on one platform or another. Apostrophes and accents survive locally and then break an upload or a script. O'Brien becomes obrien, Müller becomes muller.
7. Mixed separators. An underscore here, a hyphen there, nothing at all in the third field. Write your rule in one line and tape it to the wall: underscores divide fields, hyphens live inside them.
8. Words for versions. _final, then _final2, then _finaluse. Adjectives sort alphabetically, not chronologically, so your newest file is rarely the last one. Use _v01 and _v02, or the date.

Notice the pattern. Nothing here is about being organized. Every single one is about whether a dumb text comparison, run by software you will never think about, arrives at the answer you meant.

Folders follow the same rule, with one addition

A folder name is a file name, so it obeys everything above. The job folder is simply the file name minus the sequence:

• 2026/
• 2026/20260314_alvarez_wedding/
• 2026/20260602_chen_newborn/

The addition is inside the job folder, where alphabetical order and workflow order fight each other. Left alone, your stages sort as delivered, edits, picks, raw, which is precisely backwards. So number them:

• 01_raw, untouched camera files, never edited in place
• 02_picks, the shortlist you are going to work on
• 03_edits, exports and working files
• 04_delivered, exactly what the client received
• 05_admin, contract, shot list, invoice, notes

Two digits again, because you will eventually want a stage between 01 and 02 and you will thank yourself for leaving room. If you want the fuller argument about hierarchy depth and where an archive should live, that is its own topic and we cover it in our photo folder structure guide and the broader RAW file management guide.

Rename once, at ingest, and never again

The renaming happens in the ingest tool, during the copy from card to drive, before any other application has seen the files. Photo Mechanic, Lightroom's import panel, and most ingest utilities all do templated renaming on copy. Set the template once, save it as a preset, and the naming stops being a decision you make and becomes something that happens to you. That step belongs in a fixed routine, which is why it sits at minute thirty of our first hour after the shoot checklist.

After that, treat names as final. A catalog stores the path and file name of every image it manages, so renaming files underneath Lightroom gives you a catalog full of question marks and an evening spent reconnecting folders. If a name genuinely has to change, change it from inside the catalog so the database follows along. And never rename a file a client has already downloaded, because their copy and your copy stop matching and every conversation after that gets harder.

The reason a name set at ingest is worth this much care is that it is the last time you get to choose. From that moment the same string travels through your backup workflow, your metadata, your gallery, your invoice and your archive. It is the one identifier every part of your business agrees on, from the card in the reader to the file you dig out four years later when a couple asks for a print, and it holds together across a whole shoot to delivery workflow.

This is also why it is worth checking what your other tools do to file names. Kepla is built on the opposite principle: it picks your best shots and marks them, and every original keeps the exact name you gave it, in the exact folder you put it in. The picking app for iPhone, iPad and Mac is still being built. The booking page is live and free today.

FAQ