Terry (boss): ‘Did you submit the bid documents?’
Barry (assistant): ‘Yes, all done.’
Terry: ‘I can’t see the changes.’
Barry: ‘Look in the FINAL 2 file.’
Terry: ‘What? That wasn’t the newest version!’
Barry: ‘Oh. Right. Oh dear. Sorry.’
Trust me, you don’t want to be on either side of that conversation.
How files are named isn’t going to excite anyone (even me, and I’m a proper nerd), but it’s one of those things that can make life easier for you – if you do it right.
But get your labelling wrong and you’ll end up confusing your colleagues. In the worst case, they might ‘do a Barry’ and edit an outdated file. And that could cost you.
Here’s what you DON’T want:
Here’s another BAD example:
Tory Manifesto 2nd Draft.docx
Tory Manifesto FINAL.docx
Tory Manifesto FINAL FINAL.docx
Tory Manifesto FINAL FINAL2.docx
— Dan Douglas (@dandouglas) May 22, 2017
If only we could come up with some sensible file name conventions …
How to write better file names
Here are my tips for improving the way you name your files:
And while you’re at it:
Let’s look at what this means in practice, using the following GOOD example:
✅ Use a logical structure
A file name should describe the content or purpose of the document.
If you were producing a finance document for SprocketCo, it would make sense to start the filename with
sprocketco-finance. It’s short but informative enough to guide the reader, as it tells us the name of the client and the general type of document.
I like stating the client name (
sprocketco) first. All other SprocketCo files treated the same way would line up in a nice alphabetical list – a logical approach.
If you have more than one client’s files in the same folder, ordering the content alphabetically will mean you group the documents by client.
If different client documents aren’t ever likely to be stored together like this, you might prefer to start with the ‘purpose’ component first and then place the client name second (or elsewhere). In a simple scenario like this, it doesn’t really matter too much. The important point is to be logical in your approach.
Here’s how an alternative arrangement would look:
Follow a logical, repeatable structure to create a name that describes the purpose of the file.
✅ Use consistent separators
Separators are the symbols that go between the words in a file name. In the examples above, I’ve used a hyphen (
-) for each separator.
Some separators cause problems for file-sharing services. For example, Dropbox doesn’t like the forward slash (
/). Even if this weren’t the case, slashes in file names aren’t good, because they can be confused with longer file pathways.
Here’s an example of a file pathway on Windows:
But if the hyphen separator had been replaced by a backslash, that would make the file pathway look different:
Now, a clever clogs would say, ‘ah, but Windows doesn’t let you put backslashes into filenames anymore.’
Yes, that’s true. Here’s what happens when you try:
But, but, BUT! You can put a backslash into a file name on a Mac.
And that means a Mac user could send a badly named file to a Windows user.
Rather than risk this hassle, stick to using a separator you know will work well. Use a hyphen (
It’s also good practice (and beneficial for SEO) to use hyphens as separators for files that will be available on the web. So even if you’re consistent with the use of a different separator that doesn’t fall into the above trap, such as the underscore (
_), it’s still better to use a hyphen.
Here’s an example of what Martin means:
Use hyphens (
-) as separators.
✅ Use sequential numbering
I won’t explain how numbers work. Suffice to say that the higher the version number, the more recent the document. Version numbers should go at or very near the end of the file name.
There should be no doubt which is the newest document here:
I prefer to add a
v before the version number. This helps to separate the version number from any other number or date preceding it.
The problems come about when people dump the version numbers, instead using words such as ‘FINAL’ to act as status indicators.
This practice would be fine if you could be sure that the file really was the final version, but, as our introductory scenario above shows, that’s a dangerous game to play.
Here’s a BAD example:
Even with the rest of the structure making sense, this numbering arrangement doesn’t work well. It puts an unnecessary cognitive load on the reader. In case you haven’t worked it out, the second item in the list above is the latest version of the document.
Although I like placing the version number at the end of the file name, sometimes it helps to include the author’s initials there, especially when revisions are going back and forward between people.
Let’s say I’m sending files to my colleague Tony Markwick, who’s editing them and bouncing them back to me. We might end up labelling our files like this:
The order is still clear and we can tell who’s edited each version. The hyphen between the version number and the initials adds little, and we won’t have a fight if it’s omitted (so long as we’re consistent).
If you’ve taken even the briefest moment to consider that this beautiful arrangement might be spoiled in the event that one of the parties uses three letters for their initials rather than the standard two, please know that you have my eternal respect and admiration.
Use numbers to include document version numbers. Don’t use words such as ‘FINAL’ as status markers – you’re asking for trouble if you do.
❌ Don’t use RanDoM CApS
It’s OK to include capital letters in file names if you’re consistent about it, but I think it’s best to keep everything in lower case.
If your document is uploaded to a web server, capitalisation could pose a problem.
Some web servers are case sensitive, meaning that you could end up with two separate files that have the same name but different capitalisation rules. You should avoid this possibility by making everything lower case, for example:
Use lower case for all file names.
What about dates in file names?
The examples above include only a year in the file name. But what if you want to include a full date?
As usual, consistency is the key to success. I like being able to alphabetise on date, so when including a full date in a file name I think it’s best to write the date in this order:
yyyy-mm-dd. For example:
See how the order would mess up if you were to write this in
There’s added confusion if people use the American date system of
mm-dd-yyyy. That’s another reason why I think
yyyy-mm-dd is best.
My digital-marketing colleague Tara-Tamiko recommends using a date and time system:
Let’s sum up
Wow, that was a long post! Here’s a quick recap:
- Use a logical structure
- Use consistent separators (hyphens are best)
- Use sequential numbering
- Include dates in
- Don’t use RanDoM CApS
The overriding rule is to be consistent.
What are your file name conventions? Let me know by leaving a comment below.
Want relentlessly helpful emails? Join Espresso ☕️
Who wrote this?
John Espirian – the relentlessly helpful technical copywriter
I write B2B web content, blogs, user guides and case studies – all aimed at explaining how your products, services and processes work. I also offer LinkedIn profile critiquing and rewriting.
I work from home in Newport, South Wales and support the (formerly) mighty Liverpool FC 🔴⚽️