What is cache busting in CSS? Cache busting is a specific technique where the developer forces the browser to load the most recent version of a file, instead of the previous cached version.
There are several times when a developer makes changes and the user don’t see them because the browser enters in a so-called “cached version” mode. It’s annoying to make changes and have the user not be able to see them, right?
Think about cache busting like getting a new haircut. Yesterday, your friends saw you with big hair and you were embarrassed. But today, you have a new haircut. What you should do to update your friends about your new haircut? Post a story on Instagram or a new clip on TikTok?
Another example… You bought a new car. Congratulations! But you want to brag to your friends, which doesn’t really do you any favors. What you should do now? Take a ride around the city in your new car or call all of them?
It’s not a good move to brag, but if you have a website and you’ve made some changes, it’s a good idea to let everybody know that the website has changed. How do you do that? By using cache busting.
There are three important techniques for cache busting:
- File name versioning
- File path versioning
- Query strings
Let’s take a look to all of them!
Cache Busting | File Name Versioning
File name versioning is a technique, as the name suggests, to put the version name each time you make a change.
There are several conventions, but it’s important to be consistent and to stick with it.
Let’s take a look at the following conventions:
- Sequential numbers: you can put the version number at the end of the file, like this: “ProjectName-v1” or “ProjectName-v01”. If you want to be more granular, you can use the method “x.y.z”, known as “major.minor.patch”, for example: “ProjectName-v1.2.3”.
- ISO 8601: ISO 8601 is the global standard for date and time formats, like YYYY-MM-DD. In this case, your file name version should be “ProjectName-20260107” or more accurate, “ProjectName-2026-01-07”. You can also put the HH-MM (hour-minutes) and the initials if you have a team: “ProjectName-2026-01-07-07-43”, “ProjectName-2026-01-07-07-44-HRE”.
- Of course, there are other conventions, such as status indicator (“ProjectName_Draft”, “ProjectName_Revision”, “ProjectName_Final”), using the dash – or the underscore _ symbol. However, regardless of the convention you choose, make sure to apply it consistently from start to finish. Whether you work alone or as part of a team, keep the same convention everywhere.
By the way, have you heard about bus factor risk metric? I recommend you to read the following article: “The Bus Factor: A Silent Thread to Organizational Stability“.
The bus factor is a risk measurement technique which highlights how many people could get hit by a bus (figuratively speaking), before your entire project falls apart. Pretty cool, right?
That’s the main reason to have strong documentation and great communication within your team because you never know when your rock star might leave (join a competitor, go on vacation, get sick, etc.).
By the way, let’s enumerate some file name versions for a CSS file:
- style-v1.css
- style-v2.5.9.css
- style-2026-01-13.css
Now let’s dive into file path versioning!
Cache Busting | File Path Versioning
File path versioning is a technique which involves the location rather than just file name.
So, instead of naming a file “style-2026-01-15.css”, you place a standard file “style.css” inside a folder named “/2026-01-15/” or better, if you work in this path “/2026/01/”, you should change only the folder of the day: “/2026/01/15”, then “/2026/01/16” and so on.
File name versioning is a “human-centric” way of tracking changes, while file path versioning is a “system-centric” architecture.
I actually don’t look favorably on file path versioning because you need to change the file path every time you have a new version. But there are some good scenarios where is very useful.
Let’s say that your company have a SaaS product and after each release, you have a new folder with all files updated. In this situation, file path versioning is a mine of gold.
There is a scenario where file name versioning is worse than file path versioning: if you have an HTML page that uses 10 different icons and you update all 10 icons to _v2, you have to go into your code and change 10 different lines, but with path versioning you only change one variable (the base path).
In that way, path versioning is about scalability. It’s annoying for one file, but a lifesaver for 1000 files, right?
Remember this analogy:
- Path versioning is for machines (URLs, APIs, servers)
- Name versioning is for humans (email, desktop folders, downloads)
Do you know something about symlink (symbolic link)? Symlink is like a “portal” that makes path versioning profesional, on a superior level (although it has nothing to do with path versioning). If you want to understand and learn what are symlinks, you must read the following article: “Symlinks Demystified: Meanings, Usage, And Best Practices“.
From my perspective, query strings seems to be the best technique for cache busting.
Cache Busting | Query Strings
I had a client with a website in Laravel. It was quite old (the website), and I had to do some changes in CSS. The problem was that the changes weren’t propagating and I didn’t know what else to do.
It’s wasn’t a good option to clear the cache every time I made a change. What was the solution? Query strings! I made a query string to link that CSS file.
What is a query string? Nicely introducing the “?v=…” string after the CSS file name. A good example, after we know about file name versioning, is this one:
- <link rel=”stylesheet” href=”{{ asset(‘css/custom.css’) }}?v=2026-01-15″>
What do you say? You don’t need to change that CSS file or to copy to other location. You just have to put a query string after “?v=” and your problem will be solved. The browser will recognize that link points to a new file, but it’s just an illusion.
For a server, the query string is usually irrelevant data. Remember:
- If you ask for “custom.css”, the server gives you the file.
- If you ask for “custom.css?v=2026-01-15”, the server says: “I don’t know what ‘v=2026-01-15’ is, so I’ll just ignore it and give you ‘custom.css’ anyway.”
For a browser, the query string is a part of the URI (Uniform Resource Identifier):
- The browser looks at its memory (the cache) and asks: “Have I ever seen ‘custom.css?v=2026-01-15’?”
- If the answer is no, it is forced to download it from the server, even if it already has a file named “custom.css” from a previous version.
I think it’s useful for you (and for me) to make a distinction about URI and URL:
- URI (Uniform Resource Identifier): it’s the complete string of characters used to identify a resource.
- URL (Uniform Resource Locator): it’s a specific type of URI that tells you where the resource is and how to get it (using http/https).
Important: all URLs are URIs, but not all URIs are URLs.
In our example, we have an address like this: {{ asset(‘css/custom.css’) }}?v=2026-01-15
Let’s make it easier: https://horjarobert.com/css/custom.css?v=2026-01-15
- The URL is technically https://horjarobert.com/css/custom.css
- The query string is “?v=2026-01-15”
- The URI is everything (URL + query string): https://horjarobert.com/css/custom.css?v=2026-01-15
That being said, the browser treats the entire URI as the “key” for its cache. If even one character in the URI changes, the browser decides it’s a new resource.
To have a deeper understanding about CSS cache busting (or cache busting in general), take a look at the following statements:
- File name versioning: changes the URL
- Path name versioning: changes the URL
- Query string: changes the URI (but keeps the URL the same)
Learn & Grow
Cache busting is a technique that can also be used for JavaScript, JSON files, web fonts, PDF documents, and images, not just CSS files.
Thank you for your time! Never stop learning and building a great career in the IT field! God bless you!
“Good is good when it’s well done.”
✍ Horja Robert Emanuel
Digital Transformation Architect
