---
title: "A Date Stamped Into a File Name Was the Whole Cache Busting Plan"
canonical: https://dxdev.com/blog/2026-02-19_six-digits-that-told-the-browser-to/
datePublished: 2026-02-19
---
# The Six Digits That Told the Browser to Start Fresh

A browser that has already saved `TournamentTools250805.js` will keep handing back that old copy for as long as the page asks for that same name, so a changed file under an unchanged address never reaches anyone who visited before. The fix here was to rename the file by adding a six-digit date, turning `250805` into `260219`. The page then asked for an address the browser had never seen, and it had no stale copy to give back.

The six digits were not random. `250805` meant August 5, 2025. `260219` meant February 19, 2026. The date was the whole plan.

At first, I treated the dated name as an error to hunt down. That did not work. I spent time expecting to find a complicated reason for the change, when the name itself was the answer to a common problem: people can keep old copies of a website's files without knowing it.

The scary name for that problem is **cache-busting**. It simply means giving a changed file a new address so a browser does not keep handing someone yesterday's copy. Think of a recipe card in a kitchen drawer. If the card still has the same title, someone may keep pulling out the old one. Give the new card a different name, and there is no mix-up about which card to use.

That is what happened here. There was a JavaScript file, which is part of what makes a page do things, and a style file, which helps decide how a page looks. Both got the same new date added to their names:

```text
TournamentTools260219.js
TournamentTools260219.css
```

The page was changed to ask for those two new files, instead of the versions dated `250805`. A browser or other stop along the way had not seen those new addresses before, so it fetched them. The old files could remain in storage without affecting the page, because the page no longer named them.

There was no big new machine behind this. The site runs on older software and did not already have the kind of build process that automatically renames files, rewrites page references, and keeps a master list of what each file is called. Adding all of that just to rename a file would have meant more parts to install, maintain, and troubleshoot. It would have created a larger job to solve a smaller problem.

I can see why the dated name was the right trade in this situation. A person opening the page can read the file name and know what is live. A person returning to the work six months later does not need to decode a random string of letters and numbers or find a separate list that explains it. The date is right there in the name.

That does not make the approach perfect. It leaves three very ordinary chores in plain sight.

First, the date is not unique. Two changes made on the same day would both want the same file name. The second one could replace the first at an address a browser had already saved. That is exactly the stale-file problem the date was supposed to avoid. The method works best when a file is not changed twice in one day.

Second, old files pile up. Each new date leaves the last dated file behind, like spare labels in a drawer after the boxes have been renamed. Nothing automatically throws those old files away. Someone has to clean them up later.

Third, the finished compressed file is stored with the source code. That makes the change history harder to read, because a long, squashed line of code is not something a person can comfortably review. The useful source stays in a stable place, but the finished copy still adds clutter.

Those are real drawbacks. They are also easy to see before a release. The larger alternative would hide more work inside a new setup that this site did not otherwise need. Here, the rule was simple: make the new copy have a new dated name, then make the page ask for that name.

The same change also made the page load its copy-to-clipboard helper only once. That detail follows the same spirit. Fix the actual repeat problem in front of you. Do not build a whole new world around it unless the work truly calls for one.

The gap between `TournamentTools250805.js` and `TournamentTools260219.js` is the whole mechanism: 198 days of one name, then a new six-digit date, and a browser that had never seen that address had no old copy to hand back. The page stopped naming the `250805` files, so they could sit in storage harmlessly, and that is also why they will still be there until someone deletes them. The cost of this approach is a pile of dated leftovers, and it fails on any day the file changes twice. Those two limits are visible in the file names themselves, which is exactly what made them cheaper than a build system that would have hidden them.