Reader Stacks

Setting, Getting, and Deleting Cookies in Laravel

Cookie::queue() versus attaching a cookie directly to a response, why cookies are encrypted by default, and the correct way to actually delete one.

Setting, Getting, and Deleting Cookies in Laravel

Laravel wraps PHP's native cookie handling with a cleaner API, and — importantly — encrypts and signs cookies by default, which changes how you should think about reading and clearing them compared to raw PHP.

Setting a cookie

// Attached to a specific response
return response('OK')->cookie('preferred_theme', 'dark', 60 * 24 * 30); // minutes

// Queued to attach to the next outgoing response automatically
Cookie::queue('preferred_theme', 'dark', 60 * 24 * 30);

Cookie::queue() is useful when you're not directly returning the response yourself (inside a service class, for example) — Laravel attaches it automatically to whatever response eventually goes out.

Reading a cookie

$theme = $request->cookie('preferred_theme');
// or
$theme = Cookie::get('preferred_theme');

Deleting a cookie

return response('OK')->withoutCookie('preferred_theme');
// or, queued
Cookie::queue(Cookie::forget('preferred_theme'));

There's no separate "delete" mechanism at the HTTP level — a cookie is cleared by sending a new cookie with the same name and an expiration date in the past, which is exactly what withoutCookie()/Cookie::forget() do under the hood. Setting a cookie's value to an empty string without also expiring it does not delete it from the browser.

Why cookies are encrypted by default

Laravel's EncryptCookies middleware encrypts and signs all outgoing cookies except ones explicitly excluded — this prevents a client from reading or tampering with cookie values (like a stored preference or session identifier) even though the cookie is stored in their own browser. If you need a genuinely plaintext, client-readable cookie (for a JavaScript widget that reads it directly, for example), it has to be explicitly excluded in the middleware's $except array — the framework won't silently expose it otherwise.

Cookies vs. sessions

For anything sensitive or server-authoritative (auth state, cart contents tied to a user), prefer Laravel's session system over a raw cookie — sessions store the actual data server-side and only keep an identifier client-side, which is a meaningfully different security posture than storing the data itself in a cookie, encrypted or not.