Notes

File naming conventions nobody keeps, and what to do instead

· 3 min read

Search for file naming conventions and you will find the same advice everywhere. Start with the date in ISO format. Use lowercase. Use hyphens, not spaces. Put the project first, then the type, then a version.

It is good advice. It produces names like 2026-03-14-riot-digital-invoice-v2.pdf, which are genuinely easy to sort and scan.

It also has a hit rate of roughly zero over a year, and it is worth understanding why before you try again.

A convention is a tax on every save

The scheme asks you to compose a name at the moment you press save. That means recalling the format, knowing which project it belongs to, deciding whether this counts as v2, and typing thirty characters.

You will do that when you are filing deliberately. You will not do it when you are downloading an attachment mid conversation, or when your phone saves a photo, or when a tool exports something with its own name. Which is most files.

So you end up with a library where the twenty files you filed carefully are beautifully named and the two thousand that arrived on their own are called Scan_0042.pdf.

The other failure: conventions rot

Suppose you do keep it up. Your scheme encodes a client name that changes, a version scheme you outgrow, a project code from a system you stopped using. Two years in, the names are consistent and describe a world that no longer exists.

Renaming the back catalogue to match is a job nobody has ever finished.

What a good name actually needs

Strip away the formatting rules and a name only has to do one thing: let you recognise the file without opening it.

That usually means two or three facts. What kind of thing it is, who or what it concerns, and roughly when if the date matters. Riot Digital invoice, March. Lease for the flat. Chair by the lake.

Notice that none of those follow a convention. They are just descriptive, in the way you would describe the thing out loud. That is enough, because search is doing the work that alphabetical sorting used to do.

Stop composing names, start extracting them

Almost every file already contains its own name. An invoice has the company and the amount printed on it. A contract has the parties in the first paragraph. An email attachment has the subject line of the mail that carried it. A photo of a receipt has the shop name in the picture.

The work is not inventing a name, it is pulling the one that is already there.

That is what Stash does on the way in. It reads the file and looks for candidate names in the obvious places: the first heading, the title declared inside a PDF, the subject of the email that brought it, the first line that reads like a title. For a photograph, where none of those exist, the picture itself gets read and described.

Then it picks between the candidates rather than generating prose. The distinction matters: a name invented from nothing can be confidently wrong, while a name lifted out of the document is at worst the wrong part of a real document.

The one convention worth keeping

If you want a single rule that survives, make it this: never accept a name that is only a number or only a date.

IMG_6268, Scan_0042, document (3), Screenshot 2026-03-14 at 09.41.22. These are the names that make a library unsearchable, and they are the ones most likely to arrive by default. Everything else you can be relaxed about.

Stash treats exactly those as meaningless and replaces them. A name that already says something is left alone, because a person chose it and a person knows more about their own file than any reader does.

And keep the original

Whatever you use, do not throw away the name a file came with. Sometimes it is the only link back to where it came from, and occasionally the boring original is the thing you half remember. Stash keeps it on the item and shows it under the title.

Stash does the filing

Drop anything in and it gets read, named for what is actually inside it, and put where it belongs. Ask for it back in plain words. A hundred things free.

Open Stash