This is a complete resource on how to consistently name files for designers and artists that will work in all operating systems and under most circumstances.
As a graphic designer and illustrator who has created art assets for websites, apps, and even video games, I've come up with a battle-tested system for naming files. File nomenclature (especially when it is for general usage) is a very divisive and opinionated topic. (I do look forward to having a good discussion in the comments to see if there's anything I missed).
File naming does depend on the domain you are working in, but there are some fundamentals to good (and useful) file nomenclature systems.
Here's the short version of how I name my files:
category-file_name-tags.ext
Examples:
icon-email_moderator-dark-v01.png
icon-email_moderator-dark-v02.png
icon-email_user-dark.png
icon-email_user-light.png
icon-search.png
And the more humane version of that system (which I only use for certain type of documents):
Category - File Name - Tag - v01.ext
From that you can see how files are grouped based on their most significant category or attribute first. There's no spaces or illegal characters so that they work in pretty much every environment.
So that's my nomenclature solution for most projects. I've included my methods and wisdom from other domains so you can understand why I use this naming system as my default, and how you can apply it's principles elsewhere. As with all file naming standards, there's going to be caveats and edge cases. So keep on reading.
Principles
You'll never know how your files will be used or where they will end up. Therefore, the file names should support the widest possibility of applications, usages, and operating systems. In other words, your file name should work on as many platforms as possible.
File naming conventions are often very subjective (unless you are coding), so lets start with some well-established rules before going into my personal preferences.
Rule #1: No spaces
There's a lot of reasons why you shouldn't use spaces in your file names. Dealing with spaces in the command line can be annoying. Spaces render out as an ugly %20 in web URLs. It can be annoying for programming or writing scripts. They can cause human error since spaces are only indicated by a gap between letters.
Perhaps you don't think you'll ever use the command line or have your files hosted on the web. Trust me, you'll never know the fate of the files you create, so it's better to be safe than sorry.
Rule #2: No capital letters
Some capital letters look like other lowercase letters or numbers. For example, l vs I (lowercase "L" vs uppercase "i"), or O vs 0 (uppercase "o" vs. the number zero). Having all letters be lowercase removes most of the confusion.
Capital letters are also prone to human error when typing them. How many times have you typed something like, "THank you." Yeah. Best to keep it simple, remove the possibility of error, and save an extra key stroke per word.
Some operating systems are case sensitive while others are not, so you may run into a situation where two files are copied over each other and one file is lost, because one was named "invoice.pdf" and the other was named "Invoice.pdf". It's best to remove capital letters out of the equation to prevent that from happening.
When are capital letters okay?
In computer programming, capital letters might be required for your file names. For example, a file name for a class may have to exactly match the class name, which would be in PascalCase (first letter of every word capitalized, no spaces).
Hyphens vs. underscores
In my opinion, this is the most subjective part of file naming: when to use underscores or hyphens. It usually never matters which one you use, but there are some cases where you have to use one over the other.
As with capital letters, when writing software you have to follow the conventions of the programming language or the framework you are using. An underscore may indicate something special, especially if the file starts with an underscore. Frameworks will have a style guide that tells you when to use hyphens or underscores.
Underscores are a less safe to use for files that are uploaded to the web. Google recommends hyphens for URLs. I imagine that advice extends to file names as well (e.g. images), but I haven't seen any opinion by Google on file naming for SEO purposes. Underscores are invisible if the text is underlined, such as a hyperlink on a webpage. So all of that put together is why underscores are not recommended for the web, but it's a more loose recommendation.
But what about files on your computer? I have a hard time reading a file name if it's separated by hyphens. I find underscores to be a much more readable replacement for spaces. For most of my life, I've been using underscores for file names (outside of a programming project which may have their own rules). I've used underscores for files that have been uploaded to the web, and I've never ran into an issue. I feel confident with using underscores instead of hyphens for file names as a general rule. And yes, my files have been accessed by Linux terminals, scripts, the web, and I've had good luck with them.
The only time I've ever ran into an issue with underscores in filenames is when using Markdown to reference a file that started with an underscore. In Markdown the underscore is used to indicate when to start and stop italics. But that's the only time I've ever had a problem with it.
The important part of file naming is that the nomenclature is consistent on a per-project or per-domain basis. (By "per-domain" I mean that a software project may have different naming conventions for code than it does for the images that the code use. This is okay.) Just be as consistent as possible.
My method for naming files
So with all of those principles put together, here's how I name my files. I have a more "humane" version of this further down.
category-file_name-tags.ext
Principles:
- The most significant concept is first in the file name so files are grouped alphanumerically.
- Separate categories and tags with hyphens as the delimiter.
- Use underscores instead of spaces.
- All letters must be lowercase.
- When dates are used in a file name, they must be in the YYYY-MM-DD format, in accordance with the "most significant concept is first" principle.
- File names should be brief but descriptive.
Why do I use underscores for spaces?
The biggest reason is readability. I find hyphens to be poor separators of words, visually speaking. Yes, underscores are harder to type, but if your file name is comprised of a lot of words, then you are probably naming it wrong. File names are not meant to be sentences.
A benefit of using underscores to separate words is that most user interfaces will treat underscores as part of the word if you double-click, or use SHIFT-CTRL-ARROWKEY to select the text. Essentially, this means that each category, tag, or name can be selected independently of the other very quickly.
Categories
Categories is a term I use to describe something that I want to group files into without making a new folder for them.
Here's an example of some art assets:
grass-cut.png
grass-dead.png
grass-long.png
grass-short.png
dirt-dry.png
dirt-wet.png
See how this alphabetized file list is so easy to read? The grass and the dirt files are all grouped together.
Compare the above list to this list below, where we named them more traditionally with the adjective first:
cut_grass.png
dead_grass.png
dry_dirt.png
long_grass.png
short_grass.png
wet_dirt.png
See how the files are not grouped together? That is because we are not obeying the "most significant concept is first" rule.
Tags
A tag is a term I used to describe a slightly modified version of a file. Things like version numbering, image size, or other aspects like if it's a light mode or dark mode for that image. I put them after the file name, again in order of most to least significant.
In this example, you can see how I have tags such as "light", "dark", and "600" to help identify if a file name is supposed to be on a light or dark background, and if it's a 600 pixel wide image.
shape-cube_silhouette-dark-600.png
shape-cube_silhouette-dark.png
shape-cube_silhouette-light-600.png
shape-cube_silhouette-light.png
shape-cube_silhouette-outlined-dark-600.png
shape-cube_silhouette-outlined-dark.png
shape-cube_silhouette-outlined-light-600.png
shape-cube_silhouette-outlined-light.png
space-distance-dark-600.png
space-distance-dark.png
space-distance-light-600.png
space-distance-light.png
space-position-dark-600.png
space-position-dark.png
space-position-light-600.png
space-position-light.png
This provides a nice rhythm to the file names, making it easy to find what I'm looking for in a filename list.
Should a version number go before or after the tags?
It depends. Always follow the "most significant concept is first" principle when figuring out what tags go in what order.
My instinct is that the version number of a document will always be the last part of the file name, but there are times where you may not want that to be the case.
In the case of a logo, where I have a dark mode and a light mode, I usually have the dark and light mode version in the same source file. For example, logo-v06.afdesign is an Affinity Designer file that includes the artwork for the light and dark mode versions of the same art asset. My export options in the source file will add a -light and -dark string of text at the end of the file name, so the final will be the following:
logo-v06.afdesign
logo-v06-dark.png
logo-v06-light.png
Note that the version number is not last. That is actually the preferred scenario for me in this case where the dark and light files are inside of the source .afdesign file.
Make file names "sticky" by using two underscores at the beginning of the file name.
When I have a file named __readme.txt, the underscores at the beginning of the filename will sort it to the top of the list. I also use folder names called __old so that they are sorted separately as well.
Why do I use two underscores instead of just one? It's more noticeable. It's closer to one em's worth of length, and I like having the text indented out a little bit more.
The only time this has been a problem is when using software that incorporates linking to Markdown files, such as the note-taking app Obsidian. Underscores are used to indicate italics, or two underscores to indicate bold. That means the text starts to format as bold if I link to one of those files.
Alternately, make files sticky by starting them with a string of zeros.
This is the more future-proof method of making a file name sticky.
When using underscores in a file name is inappropriate, or if I want to force a very specific ordering system, I'll use a string of numbers at the beginning of the file name.
000-scratchpad.md
010-the-big-picture.md
020-choosing-your-tools.md
030-the-elements-of-design.md
Any file starting with 000- is considered to be sticky, as it will always show up at the top of the list.
I start my numbering at 010- and then increment each file by 10. That way if I need to insert a document in between 010 and 020 I can use 015- without having to rename every file in the directory. This is a system I have to use when writing structured content in Markdown because of how Markdown uses underscores for text formatting.
When I use hyphens instead of underscores
When I'm working on web site projects, the names for pages and directories should use hyphens instead of underscores. The reason why is because it is the standard for URLs to use hyphens to separate words because they are easier to type. From a technology standpoint, Google treats hyphens like spaces, but underscores are treated as word characters. That is why the double-click and CTRL-SHIFT-ARROWKEY trick works to select a string of text like file_name.
Google will drop the underscore and consider a word like "company_logo" as "companylogo". That might be a problem for SEO, but I haven't seen any definitive research or statement on how that applies to file names on the web, just URLs.
I think that image names with underscores should always be fine though, even for web projects. To this day I use hyphens for images and I haven't ran into any problems or concerns. If you want an image to show up in Google image search, it may be prudent to use hyphens instead of underscores. But that's just a guess.
The humane version of my naming scheme
Lets assume that you are not going to interact with a file using a command line interface, or upload it to the web, and you simply want your file names to looks as readable as possible in your folder view. You can use the same principles of the naming scheme, but modify it slightly to use spaces and capitalization.
Category - File Name - Tag - v01.ext
This follows all the same principles of my previous naming scheme, except that I don't use underscores, I use spaces and - or "space hyphen space" as a delimiter between categories, file names, and tags. Categories and tags are capitalized. The file name can be title case or sentence case; whatever case makes sense.
Advantages:
- It's a lot more readable.
Disadvantages:
- The file names are longer.
- The files will create ugly URLs if those files ever makes it to the web.
- The files are more difficult to work with through a command line.
When do I use this naming system? If I'm reasonably sure that the files won't be accessed directly through the command line (since dealing with spaces can be a pain) and that it'll never be put on a web server. I also won't use this system if the length of the file names may become a problem. An example of this would be video or graphics software where it may show a list of art assets that are used within the project. That list takes up a lot of screen real estate, and if the file names are too long I won't be able to see the entire file name. The human-readable filename of Category - File Name - Tag - v01.ext uses 6 more characters than my standard naming system, which increases the length of the file name by 20%.
I do use this naming scheme on a semi-regular basis. I use it for text documents, talks, presentations, anything that I know won't get uploaded to the web anywhere (except contained in a ZIP file) or used as an art asset for a bigger project. In short, this is my lazy naming scheme if I want things to be readable. But if I'm doing something for a project, I'll stick with the more robust and condensed naming system.
Top comments (0)