Kalkylator för HTTP-cachens giltighetstid

Ange värdena för Cache-Control, Expires, Date och Age i ett svar, tidpunkten då det mottogs och tidpunkten att kontrollera. Kalkylatorn ger färskhetstiden, den aktuella åldern och om svaret fortfarande är färskt.

Typ av cache

Cache-Control (värdet i svarshuvudet)

Expires (värdet i svarshuvudet; lämna tomt om det saknas)

Date (värdet i svarshuvudet; lämna tomt om det saknas)

Age (värdet i svarshuvudet i sekunder; lämna tomt om det saknas)

Tidpunkt då svaret mottogs (UTC)

Tidpunkt att kontrollera (UTC)

Färskhetsbedömning (vid tidpunkten att kontrollera) —

Färskhetstid (hur länge svaret kan förbli färskt; ändras inte när tiden går)
Färskhetstid	—
Källa som används	—

Aktuell ålder (tiden sedan svaret skapades; ökar när tiden går)
Aktuell ålder	—
Skenbar ålder (mottagningstid − Date)	—
Värdet i Age-huvudet	—
Ålder vid mottagandet (det större av de två ovan)	—
Tid sedan mottagandet	—

Återstående färskhet
Återstående färskhet (färskhetstid − aktuell ålder)	—
Tidpunkt då det blir inaktuellt	—

Detta är en beräkning baserad på RFC 9111. Verkliga webbläsare och CDN:er beter sig inte alltid exakt som standarden beskriver. Svarsfördröjningen sätts till 0.

Vad kalkylatorn gör

Den täcker en del av RFC 9111, standarden för HTTP-cachning: färskhetsberäkningen. Det är den del som avgör om ett lagrat svar får återanvändas utan att kontrollera med ursprungsservern. Validering (ETag, If-Modified-Since, 304), Vary och Cache-Control på förfrågningssidan ingår inte.

Färskhet är varken en uppdatering eller en radering

Att ett svar är inaktuellt betyder bara att en cache inte får återanvända det utan att först kontrollera. Det betyder inte att webbläsarens skärm uppdateras av sig själv, och det betyder inte att filen på ursprungsservern ändras eller raderas. På samma sätt betyder ett färskt svar inte att filen på servern inte har ändrats. Expires-huvudet, säger standarden, "does not imply that the original resource will change or cease to exist at, before, or after that time". Kalkylatorn räknar bara ut tidsaritmetiken för den cachade kopian.

Färskhetstid och aktuell ålder

Färskhetstid: den tidsperiod som svaret kan förbli "färskt". Den bestäms av själva svaret (Cache-Control eller Expires) och ändras inte när tiden går.
Aktuell ålder: den tid som gått sedan svaret skapades. Den ökar när tiden går.
Är det färskt? Svaret är färskt bara när färskhetstiden är längre än den aktuella åldern (när de är lika är det inaktuellt).
Återstående färskhet = färskhetstid − aktuell ålder.

Vilket värde som bestämmer färskhetstiden

Enligt avsnitt 4.2.1 i RFC 9111 används den första träffen:

Ordning	Delad cache (CDN, proxy)	Privat cache (webbläsare)
1	s-maxage	(s-maxage används inte)
2	max-age	max-age
3	Expires − Date	Expires − Date
4	Om ingen finns saknas uttrycklig utgångstid	Samma

Om max-age finns ignoreras Expires. I en delad cache ignoreras max-age och Expires om s-maxage finns (avsnitt 5.3).
Om samma direktiv förekommer flera gånger används det första (ett av de tillvägagångssätt som standarden tillåter).
Ett max-age eller s-maxage som inte är ett heltal, eller står inom citattecken (standarden säger att en avsändare inte får skapa den citerade formen), behandlas som ogiltigt, och svaret anses vara inaktuellt (färskhetstid 0). Ett värde över 2 147 483 648 behandlas som 2 147 483 648 (avsnitt 1.2.2).
Om Expires är 0 eller ett datum som inte finns behandlas svaret som redan utgånget (avsnitt 5.3).
När det inte finns någon uttrycklig utgångstid beräknas ingen heuristisk färskhet (till exempel en uppskattning utifrån Last-Modified). Standarden överlåter den heuristiska livslängden åt implementeringen.

Så räknas den aktuella åldern ut

Formlerna kommer från avsnitt 4.2.3 i RFC 9111:

Skenbar ålder = max(0, mottagningstid − Date)
Ålder vid mottagandet = max(skenbar ålder, Age-huvudet + svarsfördröjning)
Aktuell ålder = ålder vid mottagandet + tid sedan mottagandet

Kalkylatorn frågar inte efter tidpunkten då förfrågan skickades, så den sätter svarsfördröjningen (tiden från att förfrågan skickas till att svaret tas emot) till 0. På en anslutning med stor fördröjning kan den beräknade åldern bli lägre än den verkliga. Standarden tillåter också att enbart Age-huvudet plus fördröjningen används.

Regler för inmatningen

Ange datum som IMF-fixdate (till exempel Sun, 06 Nov 1994 08:49:37 GMT) eller som en UTC-tid som 2026-10-21 07:28:00. Allt anges i UTC (GMT); tidszoner hanteras inte. Året måste vara mellan 1900 och 2100, och sekunderna mellan 0 och 59 (en skottsekund, 60, accepteras inte). Veckodagen kontrolleras inte mot datumet.
Formaten RFC 850 och asctime är format som HTTP-mottagare förväntas acceptera, men den här kalkylatorn stöder dem inte. (Det betyder inte att de är ogiltiga i HTTP. Konvertera värdet till en IMF-fixdate.)
Om Date är tomt används den tid du anger som "Tidpunkt då svaret mottogs" i stället för Date. RFC 9110 säger att en mottagare som får ett svar utan Date registrerar mottagningstiden och lägger till den som Date. Om den tiden också är tom kan beräkningarna som behöver Date (Expires − Date och den skenbara åldern) inte göras. Webbläsarens aktuella tid används aldrig automatiskt; den fylls i först när du trycker på knappen för "aktuell tid", i fältet "Tidpunkt att kontrollera".
Tidpunkten som ska kontrolleras får inte vara tidigare än tidpunkten då svaret mottogs.

Andra Cache-Control-direktiv

De används inte i beräkningen, men visas som anmärkningar om återanvändning.

no-store: får inte lagras. private: en delad cache får inte lagra det (en webbläsare får).
no-cache (utan argument): även när det är färskt kan det inte återanvändas utan validering.
must-revalidate: när det väl är inaktuellt får det inte användas utan validering. proxy-revalidate: detsamma, men gäller inte en privat cache.
public: tillåter uttryckligen lagring.
immutable (RFC 8246) samt stale-while-revalidate och stale-if-error (RFC 5861) ligger utanför RFC 9111. De känns igen men används inte i beräkningen.

Exempel

Inmatning	Resultat
max-age=3600, ingen Age, 1800 s efter mottagandet	Färskhetstid 3600 s, aktuell ålder 1800 s, 1800 s återstår (färskt)
Samma, vid exakt 3600 s	Aktuell ålder 3600 s. Den är lika med färskhetstiden, så det är inaktuellt
max-age=3600, Age=600, nyss mottaget	Aktuell ålder 600 s, 3000 s återstår
Delad cache med s-maxage=60, max-age=3600	Färskhetstid 60 s (max-age ignoreras)

Bra att veta

Detta är en beräkning baserad på standarden. Verkliga webbläsare och CDN:er beter sig inte alltid exakt som standarden beskriver. Åtgärder som tvingad omladdning och CDN-specifika inställningar kan ge andra resultat. Hur en viss produkt beter sig garanteras inte.
Heuristisk färskhet, validering, Vary, förfrågningsdirektiv och sammanräkning av flera cacher ingår inte.

Källor och kontroller

Följande kontrollerades mot standardernas fulla text den 1 november 2026:

RFC 9111, "HTTP Caching": https://www.rfc-editor.org/rfc/rfc9111 (avsnitt 1.2.2, 4.2.1, 4.2.3, 5.1, 5.2.2 och 5.3, inklusive färskhetstestet freshness_lifetime > current_age)
RFC 9110, "HTTP Semantics": https://www.rfc-editor.org/rfc/rfc9110 (avsnitt 5.6.7 och 6.6.1)

Kalkylatorn följer dessa avsnitt enbart för färskhet. Att klara den här beräkningen är inget påstående om att en produkt eller en server följer standarden.

Vanliga frågor

Vad händer när både max-age och Expires finns?

max-age har företräde och Expires ignoreras (RFC 9111, avsnitt 5.3).

Gäller s-maxage för en webbläsare?

s-maxage är ett direktiv för delade cacher. En privat cache (en webbläsare) använder det inte.

Vad är Age-huvudet?

Det är antalet sekunder, skrivet av en cache på vägen, sedan svaret skapades eller senast kontrollerades hos ursprungsservern. Kalkylatorn använder det för att räkna ut den aktuella åldern.

Försvinner eller uppdateras ett inaktuellt svar av sig självt?

Nej. Inaktuellt betyder bara att en cache måste kontrollera innan den återanvänder svaret. Det uppdaterar inte skärmen och ändrar ingenting på ursprungsservern.

Hur kan jag kontrollera en tidpunkt?

Unix-tidsstämpelomvandlaren och Cron-uttrycksräknaren kan hjälpa till.