Size, Expiry, Access and Law in Local Storage vs Cookies

What is the difference between local storage and cookies?

The core difference in local storage vs cookies is where the data goes: the browser attaches cookies to HTTP requests sent to the server, while local storage stays inside the browser until a script reads it and sends it somewhere. Everything else follows from that. The WHATWG HTML Standard, which defines localStorage, says it was built for data that cookies handle badly, "because they are transmitted with every request."

Property	Cookies	Local storage
Defined in	RFC 6265, being replaced by draft-ietf-httpbis-rfc6265bis	WHATWG HTML Standard, section 12
Size	At least 4096 bytes per cookie (RFC 6265 minimum)	5 MiB per origin (MDN)
Expiry	Expires or Max-Age, or end of session	None; stays until deleted
Sent to the server	Yes, in the Cookie header of matching requests	Never, unless a script sends it
Readable by JavaScript	Yes through document.cookie, unless HttpOnly	Always, by any script in the origin
Security attributes	HttpOnly, Secure, SameSite, Domain, Path	None
Scope	Domain and path; no isolation by port	Origin: scheme, host and port
Safari ITP	Cookies set by document.cookie capped at 7 days	Deleted after 7 days of Safari use without interaction
ePrivacy Article 5(3)	Covered	Covered

How much data can a cookie and local storage hold?

A cookie holds about 4 KB and local storage holds about 5 MiB per origin, a difference of more than a thousand times. The cookie number comes from RFC 6265, section 6.1, which sets a floor, not a ceiling: user agents "SHOULD provide" at least "4096 bytes per cookie (as measured by the sum of the length of the cookie's name, value, and attributes)", at least "50 cookies per domain" and at least "3000 cookies total".

The replacement draft changes the nature of that number. In draft-ietf-httpbis-rfc6265bis-22, dated December 2025 and listed by the IETF datatracker as an active Internet-Draft headed for Proposed Standard, the browser must "ignore the cookie entirely" if "the sum of the lengths of cookie-name and cookie-value is more than 4096 octets", and each attribute value is limited to 1024 octets. The minimum to support has become a hard maximum. The history of that figure is in the piece on the cookie size limit.

The HTML Standard sets no size for local storage. It only says setItem() "Throws a QuotaExceededError if the new value couldn't be set." The working number comes from MDN's page on storage quotas: "Browsers can store up to 5 MiB of local storage, and 5 MiB of session storage per origin", with Web Storage "limited to 10 MiB of data maximum on all browsers."

From floor to ceiling

RFC 6265, the current rule

• User agents "SHOULD provide" at least 4096 bytes per cookie
• At least 50 cookies per domain
• At least 3000 cookies total
• A minimum the browser should reach, not a limit it must obey

rfc6265bis-22, the December 2025 draft

• The browser must "ignore the cookie entirely" past 4096 octets
• Each attribute value capped at 1024 octets
• The same number turned into a hard maximum

When do cookies and local storage expire?

A cookie expires when its Expires date or Max-Age runs out, or at the end of the session if it has neither, while local storage has no expiry at all. MDN states it directly: "localStorage data has no expiration time", except in private browsing, where it is "cleared when the last 'private' tab is closed." sessionStorage is the short-lived sibling and is cleared when the page session ends.

Cookies are gaining an upper limit. Section 5.5 of the rfc6265bis draft says a browser "MUST limit the maximum age of the cookie" and that "the limit SHOULD NOT be greater than 400 days (34560000 seconds) in the future."

The HTML Standard leaves deletion of local storage to the browser: "User agents may, possibly in a manner configured by the user, automatically delete stored data after a period of time." Apple used that permission.

Which one is sent with every HTTP request?

Cookies are sent with every matching HTTP request, and local storage is never sent by the browser on its own. RFC 6265 warns servers to keep cookies small "to minimize network bandwidth due to the Cookie header being included in every request." The draft adds that "many popular implementations have default limits of 8192 octets" for a header, and that exceeding them "could result in requests to the server failing."

"Matching" means the request fits the cookie's domain, path, Secure and SameSite rules. A value in local storage reaches a server only if your own script reads it and puts it into a request, a URL, or a body.

Can JavaScript read cookies and local storage?

JavaScript can read every local storage value in its origin, and every cookie except those marked HttpOnly. The Storage interface in the HTML Standard exposes exactly six members: length, key(), getItem(), setItem(), removeItem() and clear(). None of them hides a value from scripts, so any script on the page, including a third-party tag or injected code, can call localStorage.getItem().

Cookies have an opt-out. RFC 6265, section 4.1.2.6, says HttpOnly "instructs the user agent to omit the cookie when providing access to cookies via 'non-HTTP' APIs (such as a web browser API that exposes cookies to scripts)." WebKit's ITP 2.1 announcement of 21 February 2019 gives the practical rule: "Authentication cookies should be Secure and HttpOnly to protect them against man-in-the-middle attacks, cross-site scripting attacks, and speculative execution attacks." Local storage has no way to meet that rule, which is why a session token belongs in an HttpOnly cookie and not in localStorage.

What do the HttpOnly, Secure and SameSite attributes do?

The three attributes restrict who reads a cookie and when the browser sends it, and local storage has no equivalent for any of them.

• HttpOnly hides the cookie from scripts, as quoted above. A cookie set through document.cookie cannot carry it, so only a server's Set-Cookie header creates one.
• Secure, per RFC 6265 section 4.1.2.5, means "the user agent will include the cookie in an HTTP request only if the request is transmitted over a secure channel (typically HTTP over Transport Layer Security (TLS))."
• SameSite is defined in the rfc6265bis draft, section 4.1.2.7. With Strict, "the cookie will only be sent along with 'same-site' requests." With Lax, it is also sent "with 'cross-site' top-level navigations." With None, it goes with "same-site and cross-site requests." MDN adds that SameSite=None requires Secure, and that "some browsers use Lax as the default value if SameSite is not specified."

Scope differs too. Local storage belongs to one origin, meaning scheme, host and port together. Cookies are looser: RFC 6265 section 8.5 states that "cookies do not provide isolation by port", and the Domain attribute shares a cookie across subdomains.

How does Safari treat local storage and cookies?

Safari deletes local storage and every other form of script-writable storage after seven days of Safari use without user interaction on the site. WebKit announced the rule on 24 March 2020 in "Full Third-Party Cookie Blocking and More", noting that "APIs like LocalStorage have no expiry function at all." ITP deletes "all of a website's script-writable storage after seven days of Safari use without user interaction on the site." The list covers IndexedDB, LocalStorage, media keys, SessionStorage, and service worker registrations and cache.

The clock counts days of Safari use, not calendar days, and web apps added to the home screen keep their own counter. Cookies set by document.cookie had already been capped at seven days by ITP 2.1 in February 2019. Server-set cookies escape both rules: MDN's eviction section states that "cookies set by server are exempt from this eviction." The trigger conditions and the 24-hour variant are covered in how the Safari 7 day cookie limit works.

Does EU law treat local storage differently from cookies?

No. EU law treats local storage exactly like a cookie, because ePrivacy Article 5(3) regulates the act of storing and reading, not the technology. The consolidated text of Directive 2002/58/EC reads:

Member States shall ensure that the storing of information, or the gaining of access to information already stored, in the terminal equipment of a subscriber or user is only allowed on condition that the subscriber or user concerned has given his or her consent, having been provided with clear and comprehensive information, in accordance with Directive 95/46/EC, inter alia, about the purposes of the processing. This shall not prevent any technical storage or access for the sole purpose of carrying out the transmission of a communication over an electronic communications network, or as strictly necessary in order for the provider of an information society service explicitly requested by the subscriber or user to provide the service.

The word "cookie" does not appear. The EDPB's Guidelines 2/2023 on the technical scope of Article 5(3), version 2.0 adopted on 7 October 2024, say at paragraph 37 that the directive places no "upper or lower limit on the length of time that information must persist on a storage medium to be counted as stored, nor is there an upper or lower limit on the amount of information to be stored." Paragraph 44 names "cookies, local storage, WebSQL" together. It also draws the one line that separates them in practice: a browser using that information strictly inside the device is not "gaining of access" "as long as the information does not leave the device, but when this information or any derivation of this information is accessed, Article 5(3) ePD would apply."

So a script that writes an identifier to localStorage and later sends it to a server stores and accesses information, and needs consent unless an exemption applies. Moving a tracking ID from a cookie into local storage changes the browser behaviour and leaves the legal answer unchanged, which is why a tool described as cookieless tracking still has to say what it stores on the device. The exemptions work the same way for both. They turn on purpose, not technology, so a use that counts as "strictly necessary" in a cookie counts on the same reasoning in local storage, and a use that needs consent in a cookie needs it in local storage too.

Frequently asked questions

Is local storage more secure than cookies?

No. Any script in the origin can read local storage, and it has no equivalent of HttpOnly. WebKit advises keeping authentication in Secure and HttpOnly cookies for that reason.

Does local storage need a cookie banner?

It needs the same consent as a cookie when it is not strictly necessary. ePrivacy Article 5(3) covers "the storing of information" on the device, whatever the storage API.

What is the size limit of local storage?

MDN gives 5 MiB per origin, plus 5 MiB of session storage. The HTML Standard sets no figure; setItem() throws QuotaExceededError when a write fails.

Does local storage expire?

No. Local storage has no expiry attribute, though browsers still delete it: Safari's ITP after seven days of Safari use without interaction, and private browsing when the last private tab closes.

Can the server read local storage?

No. The browser never sends local storage in a request. The server sees a value only if a script reads it and sends it, while cookies go into the Cookie header automatically.

Is sessionStorage different from localStorage?

Yes. sessionStorage belongs to one tab and is cleared when that page session ends, while localStorage is shared across tabs of the origin and persists. Both fall under Safari's seven-day rule.

Can a session token live safely in local storage?

A session token belongs in a cookie marked Secure and HttpOnly, not in local storage, because any script in the origin can call localStorage.getItem() and read it. WebKit's ITP 2.1 announcement makes the same point for authentication cookies. Local storage has no attribute that hides a value from scripts.

How long can a cookie last under the newest cookie draft?

The rfc6265bis draft caps cookie lifetime for the first time: section 5.5 requires the browser to limit the maximum age of a cookie, and recommends that the limit not exceed 400 days. Local storage carries no such rule in the HTML Standard, which only lets the browser delete stored data at its own discretion.

Do cookies and local storage share data across subdomains?

A cookie can be shared across subdomains through the Domain attribute, and RFC 6265 notes that cookies do not provide isolation by port. Local storage has no such option: it belongs to one origin, defined as scheme, host and port together, so a script on a subdomain cannot read the parent domain's local storage.

What happens to a cookie that exceeds the 4096 byte draft limit?

Under draft-ietf-httpbis-rfc6265bis-22, the browser must ignore the cookie entirely once the combined length of its name and value passes 4096 octets. That turns the old RFC 6265 minimum, a floor user agents SHOULD provide, into a hard ceiling. The HTML Standard sets no comparable cutoff for local storage; setItem() only throws QuotaExceededError when the new value could not be set.