Больше данных хранится в cookie или в localStorage

На вопрос "где хранится больше данных" прямой ответ такой: обычно в localStorage. Cookie рассчитаны на маленькие значения, потому что они участвуют в HTTP-запросах. localStorage рассчитан на клиентское хранение и обычно дает несколько мегабайт на origin.

Но сильный ответ должен сразу добавить ограничение. localStorage не является базой данных без лимитов. Квота зависит от браузера, режима, устройства и политики хранения. Если квота закончилась, запись может выбросить ошибку, и интерфейс не должен ломаться.

Cookie отличаются от localStorage не только лимитом. Подходящие cookie браузер автоматически добавляет в HTTP-запросы к домену и пути. Если положить туда большой JSON, каждый запрос может получить лишние байты в заголовках.

Практический риск простой: медленнее сеть, больше трафика, выше шанс упереться в ограничения на размер заголовков. Поэтому cookie хороши для небольших значений, которые действительно нужны серверу, например идентификатора сессии.

На интервью удобно отвечать через сценарий. Если серверу нужно получать значение автоматически, выбирайте cookie. Если это клиентская настройка вроде темы, закрытого баннера или небольшого кеша, можно использовать localStorage. Если данных много и они структурированные, localStorage уже слабый вариант.

Главная ловушка в теме: "localStorage больше, значит туда можно положить все". Так говорить опасно. Данные в localStorage доступны любому JavaScript-коду на странице. Если в приложении случится XSS, злоумышленник сможет прочитать токен или другие секреты.

Cookie тоже не магически безопасны. Но у них есть атрибуты, которые помогают строить сессии: HttpOnly скрывает cookie от JavaScript, Secure требует HTTPS, SameSite снижает риск CSRF в типичных сценариях. Важно сказать, что HttpOnly выставляется сервером через Set-Cookie, а не через document.cookie.

localStorage существует только в браузере. Если читать его на верхнем уровне модуля или во время серверного рендера, SSR-страница может упасть с ошибкой, а React может получить разные начальные значения на сервере и клиенте.

Безопаснее иметь дефолтное состояние, а браузерное значение читать после mount или за проверкой typeof window !== "undefined". Для UI это означает: сначала показываем предсказуемую дефолтную тему или skeleton, потом аккуратно применяем сохраненную настройку без падения страницы.

Нормальный сценарий для localStorage: сохранить небольшую нечувствительную настройку интерфейса.

try {
  localStorage.setItem("theme", "dark");
} catch (error) {
  // Хранилище может быть недоступно или переполнено.
  // Интерфейс должен остаться рабочим с дефолтной темой.
}

Плохой вариант: хранить здесь пароль, refresh token или большой кеш каталога. В первом случае вы получаете риск кражи при XSS, во втором можете заблокировать основной поток и упереться в квоту.

Cookie для сессии обычно задает сервер, потому что только сервер может выставить HttpOnly.

Set-Cookie: sid=abc123; HttpOnly; Secure; SameSite=Lax; Path=/; Max-Age=3600

Если вы создаете cookie из браузера через document.cookie, не говорите, что можете сделать ее HttpOnly. Такую cookie JavaScript сможет читать и менять в пределах правил домена, пути и политики браузера.

Хорошая формулировка не спорит о точной цифре лимита. Она показывает, что вы понимаете назначение механизмов.

"Больше обычно помещается в localStorage, потому что cookie маленькие, около нескольких килобайт, и автоматически уходят с запросами. Но я не стал бы хранить в localStorage секреты или большие структуры. Для сессии лучше cookie с правильными атрибутами, а для большого клиентского кеша лучше IndexedDB".