Caching
How X caches cards and how to refresh one
Why X keeps showing an old card image or title, how long the card cache lasts, and the reliable ways to get a fresh card without the old validator.
Short answer
X stores card data per URL and, according to its troubleshooting guide, re-reads a page's tags roughly every seven days, while images are cached by their own URL; to see changes sooner, post a slightly different page URL and give changed images a new file name or query string.
Key takeaways
- Page tags and images are cached separately, both keyed by URL.
- X says it re-reads tags about every seven days; you cannot force a refresh from outside.
- A new query string on the page URL gives you a fresh fetch for testing.
- Rename replaced images instead of overwriting them.
You fixed the title and swapped the image, deployed, posted the link, and X showed the old card anyway. Nothing is broken. X saved what it saw last time and is reusing it. Understanding how that cache is keyed tells you how to get around it.
How long does X cache a card?
X's troubleshooting guide says its crawler re-indexes a page's card tags roughly every seven days. Until that happens, new posts of the same URL get the stored card. Seven days is approximate, and there is no public way to trigger a re-crawl for a specific URL.
There are actually two caches to think about:
| What | Keyed by | What changes it |
|---|---|---|
| Card data (title, description, image URL, type) | The exact page URL, query string included | A re-crawl, roughly weekly, or a different URL |
| The image itself | The image URL | A different image URL |
The second row is the one that catches people. If you upload a new picture to the same address, /og/launch.png, X can keep serving the old picture even after it re-reads your tags, because as far as it can tell the image URL has not changed.
How do I see my updated card right away?
Post a URL X has not seen before, such as the same page with a harmless query string added.
- Deploy the change and confirm the new tags are in View Source. Check your own CDN is not serving a stale copy of the HTML.
- If the image changed, make sure its URL changed too:
launch-v2.png, orlaunch.png?v=2. - In the X composer, paste the page URL with something new on the end, for example
https://example.com/launch/?v=2. - Wait a few seconds for the preview. It reflects a fresh fetch.
Your page should carry <link rel="canonical"> pointing at the clean URL, so the variant does not create duplicate pages in search. The query string is only for testing, or for a post where you really need the new card today.
What about the old way, the Card Validator?
It no longer refreshes cards. In August 2022 Twitter announced that it had removed the preview from the Card Validator and that entering a URL there would no longer update card information. The composer became the recommended way to preview. Old tutorials telling you to "run the URL through the validator to clear the cache" predate that change.
How should I name images so this never bites?
Treat published image URLs as permanent and give every new version a new URL. Three common patterns:
- Content hash in the file name, such as
og/launch.3f9a1c.png. Most build tools can do this. The name changes only when the image does. - Version query string, such as
og/launch.png?v=3. Easy to add by hand; make sure your CDN treats the query string as part of the cache key. - Date or slug-based names, such as
og/2026-11-launch.png. Fine for images that rarely change.
Keep old images available for a while. Posts already on X, Facebook and elsewhere point at the old URL, and Meta's documentation makes the same point for Facebook: replacing an image means using a new URL and leaving the old one in place.
Other platforms cache too
| Platform | Cache behavior | Refresh option |
|---|---|---|
| X | Tags re-read about weekly; images by URL | New URL variant |
| Images cached by URL | Sharing Debugger "Scrape Again" | |
| Caches previews | Post Inspector | |
| Slack | Responses cached about 30 minutes across the service | Wait, or vary the URL |
| Discord | Previews cached about 30 minutes | New query string |
So if you change a card at noon and need it correct everywhere by the afternoon, version the image URL, re-scrape on Facebook and LinkedIn with their tools, and post to X with a URL variant.
Checking that the change really deployed
Caches inside your own stack can look exactly like X's cache. Before blaming X:
- Fetch the page with
curl -s https://example.com/launch/ | grep -i 'og:image\|twitter:'and confirm the new values. - Fetch the image URL and check its
Last-ModifiedorETagchanged. - Paste the fetched head into the Card Preview & Meta Inspector to confirm the tags are well formed.
If your server returns the new tags and the image URL is new, a fresh URL variant in the composer will show the new card. If it does not, the problem is not the cache; see why my X card is not showing.
Questions
Can I clear X's cache for my URL?
Not directly. The Card Validator used to refresh a URL when you checked it, but since its preview was removed in August 2022 entering a URL there no longer updates the card. Wait for the re-crawl or use a URL variant.
Will posts I already published update?
They show whatever card X has stored for that URL. Once X re-crawls the page they can pick up the new card, but you should not count on an exact time.
Does adding ?v=2 hurt SEO?
Not if your page has a canonical link pointing to the clean URL, which it should anyway. Search engines treat the query string version as a duplicate of the canonical.
Do link shorteners help?
Old advice suggested posting a shortened link so X fetches a 'new' URL. A query string does the same thing without a third-party redirect in front of your link.