Salesforce Stack Exchange is a question and answer site for Salesforce administrators, implementation experts, developers and anybody in-between. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

There is a question about getting the path to Static Resources dynamically in apex and it has some good answers. Here it is for reference.

Dynamically get the path to a static resource

However, I've noticed that at some point, (I'm not sure when). Using the static resource url without the timestamp in it has started working fine.


works just as well as


I haven't been able to find anything about this in the documentation or release notes. So my question is...

Is using the first method without the timestamp dangerous and unsupported? Can anyone think of drawbacks? Is caching behavior changed?

share|improve this question
up vote 4 down vote accepted

The timestamp is essentially a version. Each new upload revs the timestamp. Without it, browsers cache the resource and each subsequent page load will pull from cache. Even if you upload a new version, any user who has already hit your page will have the cached version and the only way for them to get the new version is to dump their cache.

share|improve this answer

This behavior is not new.

Building the URL without the timestamp is not dangerous but it's also not the recommended approach to referencing a static resource.

The number in the URL is the number of milliseconds elapsed since Jan 1, 1970 and it is a cache-buster to provide uniqueness and ensure that the resource isn't pulled from the browser's cache and will instead be retrieved fresh from Salesforce.

If you're building one of these resource URLs manually in apex, you could use the DateTime.getTime() method to get the current number of ms and add that value into your URL.

share|improve this answer
Thanks, that's what I thought, but it's good to have some verification on this. I accepted the answer by @greenstork because he posted first, but I appreciate the answer. – plusplusben May 22 '14 at 17:56
One downside to using DateTime.getTime() to insert your own timestamp is that you force the browser to re-download the resource everytime your page loads, whether or not it has changed, thus defeating the purpose of caching. You'll increase the amount of bandwidth you use and the load time of the page. – JDB Jan 15 at 20:06

To further emphasise Mark's last comment, this code makes use of JavaScript's for the same purpose - very useful for JavaScript apps that need to access many static resources. So a timestamp is needed, it just doesn't have to be the exact timestamp of the static resource.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.