Có bao giờ bạn cặm cụi điền một form dài ngoằng, lỡ tay refresh lại trang và… mất sạch? Mình đã từng! Cảm giác lúc đó thực sự muốn đập bàn phím. Đó là lúc mình nhận ra việc hiểu rõ cách trình duyệt lưu trữ client-side quan trọng đến mức nào đối với trải nghiệm người dùng.
Vấn đề cốt lõi nằm ở việc chọn đúng công cụ: localStorage cho dữ liệu cần tồn tại lâu dài và sessionStorage cho dữ liệu chỉ sống trong một phiên làm việc. Hiểu sai một ly là đi tong cả buổi code. Với tư cách là một người đã lăn lộn 10 năm với nghề, hôm nay tại Phạm Hải, mình sẽ giúp bạn làm chủ hoàn toàn Local Storage Session Storage JavaScript để không bao giờ lặp lại những lỗi ngớ ngẩn đó nữa.
Phân biệt localStorage và sessionStorage: Bảng so sánh thần thánh
Điểm khác biệt lớn nhất giữa localStorage và sessionStorage nằm ở thời gian sống của dữ liệu: localStorage lưu trữ vĩnh viễn cho đến khi bị xóa, trong khi sessionStorage chỉ tồn tại trong một phiên làm việc của tab trình duyệt.
Để phân biệt localStorage và sessionStorage JavaScript một cách trực quan nhất, mình thường dùng bảng so sánh dưới đây. Nếu bạn mới bắt đầu Học JavaScript cơ bản cho người mới 2026, việc nắm rõ hai khái niệm này là bước đệm bắt buộc.
| Tiêu chí | localStorage | sessionStorage |
|---|---|---|
| Thời gian sống | Vĩnh viễn (đến khi xóa thủ công) | Xóa ngay khi đóng tab/trình duyệt |
| Phạm vi chia sẻ | Giữa các tab/cửa sổ cùng Origin | Chỉ nội trong một tab duy nhất |
| Dung lượng | ~5MB – 10MB | ~5MB – 10MB |
Vòng đời dữ liệu: Ai “sống lâu”, ai “chết yểu”?
LocalStorage có tính bền bỉ cao, dữ liệu không bao giờ tự động hết hạn. Ngược lại, sessionStorage sẽ bị xóa sạch ngay khi bạn đóng tab hoặc cửa sổ trình duyệt.
Đây chính là chìa khóa cho cách duy trì dữ liệu trong trình duyệt JavaScript. Khi mình làm tính năng “Ghi nhớ đăng nhập”, mình dùng localStorage. Người dùng tắt máy, hôm sau mở lại vẫn còn nguyên. Nhưng với sessionStorage, tuổi thọ của nó gắn liền với một phiên trình duyệt duy nhất. Tải lại trang (F5) thì dữ liệu vẫn còn, nhưng hễ nhấn nút “X” đóng tab là mọi thứ “bay màu”.
Phạm vi truy cập: Dữ liệu chia sẻ chung hay của riêng tab nào?
LocalStorage chia sẻ dữ liệu giữa tất cả các tab và cửa sổ có cùng một Origin. SessionStorage thì ích kỷ hơn, nó bị cô lập và chỉ có thể truy cập nội trong tab đã tạo ra nó.
Origin ở đây bao gồm sự kết hợp của giao thức (http/https), tên miền và cổng (port). Nếu bạn mở 3 tab cùng trang phamhai.com, cả 3 tab này đều đọc chung một “cuốn sổ” localStorage. Nhưng với sessionStorage, tab A không thể ngó sang xem tab B đang lưu cái gì, dù chúng mở cùng một URL.
Dung lượng lưu trữ: “Nhà kho” của ai lớn hơn?
Cả hai đều cung cấp dung lượng lưu trữ lớn hơn nhiều so với Cookies, thường giới hạn ở mức 5MB đến 10MB cho mỗi Origin tùy thuộc vào trình duyệt.
Theo các cập nhật mới nhất vào năm 2026, giới hạn dung lượng localStorage và sessionStorage trên Chrome hay Firefox vẫn duy trì ổn định quanh mức 5MB cho mỗi miền,. Nếu bạn cố nhồi nhét vượt quá con số này, trình duyệt sẽ ném thẳng vào mặt bạn một lỗi QuotaExceededError. Do đó, đừng biến chúng thành nơi chứa database thu nhỏ.
Thực hành ngay và luôn: Các phương thức Web Storage API cơ bản
Web Storage API cung cấp các phương thức đồng bộ, dễ sử dụng như setItem(), getItem(), removeItem() và clear() để thao tác với cặp khóa-giá trị.
Hai anh em nhà này đều kế thừa từ chung một giao diện Web Storage API. Chúng hoạt động theo cơ chế cặp khóa-giá trị (key-value pairs) và là một API đồng bộ (chạy tuần tự, chặn luồng chính nếu xử lý quá nhiều). Sau khi lấy dữ liệu thành công, bạn thường dùng DOM JavaScript thao tác phần tử HTML để hiển thị thông tin đó lên giao diện cho người dùng xem.
Cách sử dụng localStorage: “Ghi sổ” cho trình duyệt
Để lưu dữ liệu lâu dài, bạn sử dụng localStorage.setItem('key', 'value') và lấy lại bằng localStorage.getItem('key').
Đây là hướng dẫn sử dụng localStorage cơ bản nhất mà bất kỳ ai cũng phải thuộc nằm lòng. Dưới đây là đoạn code cách sử dụng localStorage trong JavaScript mà mình hay dùng:
- Lưu dữ liệu:
localStorage.setItem('username', 'PhamHai'); - Lấy dữ liệu:
let user = localStorage.getItem('username'); - Xóa một mục:
localStorage.removeItem('username'); - Xóa sạch sành sanh:
localStorage.clear();
Cách sử dụng sessionStorage: Dữ liệu “sớm nở tối tàn”
Tương tự như trên, bạn gọi các phương thức thông qua đối tượng sessionStorage. Dữ liệu lưu bằng sessionStorage.setItem() sẽ bốc hơi khi đóng tab.
Cú pháp cách sử dụng sessionStorage trong JavaScript giống hệt 100%. Bạn chỉ cần thay chữ local thành session:
- Lưu tạm:
sessionStorage.setItem('step', '2'); - Lấy ra:
let currentStep = sessionStorage.getItem('step');
Mẹo hay: Lưu đối tượng/array vào localStorage bằng JSON
Vì Web Storage chỉ lưu chuỗi, bạn bắt buộc phải dùng JSON.stringify() để chuyển đổi khi lưu đối tượng vào localStorage JavaScript và dùng JSON.parse() khi lấy ra.
Rất nhiều bạn mới hay gặp lỗi lưu thẳng [object Object] vào kho. Web Storage không hiểu kiểu dữ liệu phức tạp như mảng hay object. Để lưu đối tượng vào localStorage JavaScript, bạn phải biến nó thành chuỗi. Kết hợp với các cú pháp ES6 JavaScript tính năng mới cần biết, việc xử lý object trở nên cực kỳ gọn gàng.
const user = { name: "Hải", role: "Admin" };
// Lưu vào
localStorage.setItem('user_info', JSON.stringify(user));
// Lấy ra
const parsedUser = JSON.parse(localStorage.getItem('user_info'));
Cuộc chiến tay ba: So sánh localStorage, sessionStorage và “ông già” Cookies
Cookies chủ yếu dùng để giao tiếp với server qua HTTP headers, trong khi localStorage và sessionStorage (Web Storage) được thiết kế chuyên biệt cho việc lưu trữ client-side với dung lượng lớn hơn.
Khi so sánh localStorage sessionStorage và cookies, mình luôn nhấn mạnh về mục đích ra đời. Cookies có từ thời kỳ đồ đá của web, sinh ra để server nhớ mặt client. Còn Web Storage là thế hệ mới, sinh ra để giảm tải cho server và tăng sức mạnh cho trình duyệt.
Khi nào nên “phản bội” Cookies để theo Web Storage?
Hãy chọn Web Storage khi bạn cần lưu trữ dữ liệu phía máy khách JavaScript với dung lượng lớn (trên 4KB) và không cần gửi dữ liệu đó lên server trong mỗi request.
Việc lưu trữ dữ liệu phía máy khách JavaScript bằng Cookies rất hạn chế vì nó chỉ chứa được khoảng 4KB. Thêm vào đó, nếu bạn lưu 4KB vào Cookies, mỗi lần bạn tải một tấm ảnh hay gọi API, 4KB đó đều chạy theo lên server. Web Storage giải quyết triệt để sự lãng phí này.
Tại sao không gửi Web Storage qua HTTP header?
Web Storage API hoàn toàn tách biệt với các HTTP requests. Điều này giúp tiết kiệm băng thông mạng đáng kể vì dữ liệu không bị đính kèm tự động như Cookies.
Không giống như Cookies luôn bám đuôi các HTTP headers gửi về máy chủ, dữ liệu của Web Storage nằm ngoan ngoãn ở trình duyệt. Server không hề biết sự tồn tại của chúng trừ khi bạn chủ động lấy ra bằng JavaScript và nhét vào body của một cục API request gửi đi.
Ứng dụng thực tế: Khi nào dùng localStorage và sessionStorage?
Việc chọn công cụ phụ thuộc vào kịch bản: localStorage cho dữ liệu cần giữ lại qua nhiều lần truy cập, và sessionStorage cho trạng thái ứng dụng tạm thời.
Để biết chính xác khi nào dùng localStorage và sessionStorage, hãy tự hỏi: “Dữ liệu này có cần sống sót qua đêm không?”. Dù bạn đang Học HTML CSS cơ bản cho người mới bắt đầu hay làm frontend nâng cao, hiểu rõ ví dụ ứng dụng localStorage sessionStorage thực tế là rất cần thiết để thiết kế luồng người dùng (UX) chuẩn xác.
Các kịch bản nên dùng localStorage: Ghi nhớ tùy chọn người dùng, giỏ hàng, mã thông báo xác thực (JWT)
LocalStorage tỏa sáng khi lưu theme (dark/light mode), giỏ hàng chưa đăng nhập, hoặc mã thông báo xác thực (JWT) trong các ứng dụng SPA (dù cần lưu ý bảo mật).
- Tùy chọn người dùng: Lưu ngôn ngữ đã chọn, giao diện sáng/tối.
- Giỏ hàng: Khách vãng lai thêm đồ vào giỏ nhưng chưa đăng nhập, bạn lưu tạm vào đây để họ quay lại ngày mai không bị mất.
- Mã thông báo xác thực: Trong nhiều dự án React/Vue, người ta vẫn dùng nó để lưu JWT token. Tuy nhiên, vào năm 2026, xu hướng bảo mật khuyến cáo nên cẩn trọng với cách này do rủi ro XSS,.
Các kịch bản nên dùng sessionStorage: Lưu trạng thái form nhiều bước, dữ liệu tạm thời cho một lần truy cập
SessionStorage là chân ái cho các form đăng ký nhiều bước (multi-step forms) hoặc lưu trạng thái ứng dụng tạm thời để tránh mất dữ liệu khi vô tình F5.
- Trạng thái ứng dụng: Bạn đang kéo danh sách sản phẩm đến trang thứ 3, bấm vào xem chi tiết rồi ấn nút “Back”. Dùng sessionStorage để nhớ vị trí cuộn trang.
- Khi xây dựng form bằng HTML5 Semantic thẻ ngữ nghĩa chuẩn SEO, kết hợp sessionStorage giúp UX tăng lên đáng kể. Khách điền đến bước 3 lỡ F5 vẫn không phải gõ lại từ đầu.
Góc khuất ít ai để ý: Bảo mật và những cú “phốt” tiềm tàng
Dữ liệu trong Web Storage có thể bị truy cập dễ dàng bằng JavaScript, do đó nó cực kỳ dễ bị tổn thương trước các cuộc tấn công XSS nếu không được mã hóa cẩn thận.
Chủ đề localStorage và sessionStorage bảo mật luôn là thứ khiến các dev đau đầu. Bảo mật web không chỉ là chuyện của backend. Ngay cả khi tối ưu tốc độ tải trang với defer và async javascript wordpress, bạn cũng không được lơ là việc kiểm soát các script chạy trên trang của mình.
Hiểm họa tấn công XSS: Đừng bao giờ lưu dữ liệu nhạy cảm!
Bất kỳ script độc hại nào chạy trên trang của bạn đều có thể đọc được localStorage. Tuyệt đối không lưu mật khẩu, thông tin thẻ tín dụng hay PII (thông tin định danh cá nhân) ở đây.
Tấn công XSS (Cross-Site Scripting) xảy ra khi hacker chèn được một đoạn mã JS lạ vào trang của bạn. Đoạn mã này chỉ cần gọi localStorage.getItem('jwt_token') và gửi về server của chúng là xong phim,. Tại Phạm Hải, nguyên tắc bất di bất dịch của tụi mình là: Dữ liệu nhạy cảm phải nằm ở HttpOnly Cookies, tuyệt đối không vứt hớ hênh ở Web Storage,.
Nguyên tắc Origin và cách trình duyệt cô lập dữ liệu
Trình duyệt áp dụng chính sách Same-Origin Policy. Dữ liệu lưu ở http://domain.com sẽ không thể bị truy cập bởi https://domain.com hoặc các sub-domain khác.
Đây là một tính năng bảo mật tuyệt vời của HTML5. Nhờ quy tắc Origin, trang web của hacker không thể tự ý mò sang đọc Web Storage của trang ngân hàng bạn đang mở. Bạn có thể tự mình kiểm chứng điều này bằng cách mở Công cụ nhà phát triển (DevTools -> tab Application/Storage) để xem dữ liệu bị cô lập theo từng domain như thế nào.
Tóm lại, đừng coi thường hai “anh em” nhà Web Storage này. Đánh giá ưu nhược điểm của localStorage và ưu nhược điểm của sessionStorage, chúng ta thấy chúng mang lại tốc độ và sự tiện lợi tuyệt vời cho frontend, nhưng lại thiếu đi lớp giáp bảo mật vững chắc trước XSS. Chúng không phải là giải pháp cho mọi bài toán lưu trữ. Nếu bạn cần lưu trữ dữ liệu cấu trúc phức tạp với dung lượng khổng lồ, hãy tìm hiểu thêm về IndexedDB hoặc kết hợp với Service Workers. Nắm vững bản chất của Local Storage Session Storage JavaScript, chọn đúng vũ khí trong đúng hoàn cảnh, bạn sẽ tránh được vô số bug ngớ ngẩn và code “sạch” hơn rất nhiều.
Bạn đã bao giờ “dính chưởng” mất sạch dữ liệu form hay đau đầu vì lỗi bảo mật với Web Storage chưa? Hãy chia sẻ cú ngã “để đời” của bạn ở phần bình luận bên dưới nhé, mình cùng học hỏi!
Lưu ý: Các thông tin trong bài viết này chỉ mang tính chất tham khảo. Để có được lời khuyên tốt nhất, vui lòng liên hệ trực tiếp với chúng tôi để được tư vấn cụ thể dựa trên nhu cầu thực tế của bạn.
