Tra cứu nhanh mức hỗ trợ CSS và JavaScript trên bốn trình duyệt chính
Bảng tra cứu tự chứa gồm hơn năm mươi tính năng CSS và JavaScript hiện đại được tìm kiếm nhiều nhất, kèm phiên bản trình duyệt bắt đầu hỗ trợ trên Chrome, Firefox, Safari và Edge. Lọc theo tên tính năng hoặc theo nhóm CSS, JavaScript, Web API để nhanh chóng biết một API hay thuộc tính có dùng được an toàn cho tệp người dùng của bạn hay chưa, mà không cần rời khỏi trang.
Tính năng nổi bật
- Hơn năm mươi tính năng CSS, JavaScript và Web API được tuyển chọn theo mức độ tìm kiếm và mức độ dùng phổ biến trong dự án thực tế
- Mỗi tính năng hiện phiên bản bắt đầu hỗ trợ ổn định trên Chrome, Firefox, Safari và Edge
- Phân ba mức hỗ trợ rõ ràng: hỗ trợ đầy đủ, hỗ trợ một phần kèm ghi chú điều kiện, và không hỗ trợ
- Ô tìm kiếm lọc theo tên hoặc mô tả tính năng, gõ có dấu hay không dấu đều được, không cần cuộn qua toàn bộ bảng
- Bộ lọc theo nhóm CSS, JavaScript, Web API để thu hẹp phạm vi tra cứu
- Ghi chú riêng cho các trường hợp đặc biệt, ví dụ tính năng cần tiền tố trình duyệt hoặc chỉ hỗ trợ một phần chức năng
- Dữ liệu tĩnh biên soạn thủ công theo caniuse.com và MDN, rà soát lần cuối tháng 9/2026; tính năng còn đang triển khai được ghi rõ là cần xác minh thay vì đoán số phiên bản
- Hoạt động hoàn toàn ngoại tuyến sau khi tải trang, không gọi API bên ngoài để lấy dữ liệu hỗ trợ
Vì sao cần một bảng tra cứu tự chứa thay vì luôn mở caniuse.com
caniuse.com và bảng tương thích của MDN là hai nguồn tham chiếu chuẩn xác và cập nhật nhất cho câu hỏi "tính năng này dùng được từ phiên bản nào", và công cụ này không có tham vọng thay thế hai nguồn đó. Vấn đề thực tế là trong lúc code, việc phải mở tab mới, gõ tên tính năng, chờ trang tải, rồi đọc một bảng dữ liệu dày đặc thường làm gián đoạn luồng làm việc hơn mức cần thiết cho một câu hỏi tra cứu nhanh. Công cụ này gom sẵn những tính năng hay được hỏi nhất — từ CSS Grid, :has(), container queries cho tới structuredClone, top-level await, Web Share API — vào một bảng duy nhất có thể lọc và tìm kiếm ngay lập tức, phù hợp cho việc kiểm tra nhanh trong lúc viết mã hoặc trong buổi họp quyết định có nên dùng một tính năng mới hay chưa. Với quyết định thực sự quan trọng, đặc biệt khi cần biết chính xác đến từng bản build của Safari trên iOS, việc mở lại caniuse.com vẫn là bước không thể bỏ qua.
Lợi ích khi sử dụng
- Tra cứu nhanh ngay trong lúc code mà không cần rời trang hay chờ tải một trang bên ngoài
- Gom sẵn những tính năng hay được hỏi nhất, không cần nhớ tên chính xác theo caniuse.com
- Phân loại rõ ba mức hỗ trợ thay vì chỉ có hoặc không, phản ánh đúng thực tế nhiều tính năng chỉ hỗ trợ một phần
- Ghi chú điều kiện đặc biệt ngay tại chỗ, ví dụ tiền tố trình duyệt hay giới hạn nền tảng
- Không cần kết nối mạng sau khi tải trang, phù hợp để tra cứu nhanh cả khi mạng chậm
Cách dùng Browser Compatibility Checker
- 1Gõ tên tính năng bạn cần tra vào ô tìm kiếm, ví dụ "has", "container", "backdrop" hoặc "share".
- 2Hoặc bấm vào một trong ba nhóm CSS, JavaScript, Web API để thu hẹp danh sách theo loại tính năng.
- 3Đọc badge màu ở mỗi ô trình duyệt: xanh lá là hỗ trợ đầy đủ, vàng là hỗ trợ một phần kèm ghi chú điều kiện, đỏ là chưa hỗ trợ.
- 4Chú ý phần ghi chú màu vàng bên dưới tên tính năng nếu có, vì đó thường là điều kiện quan trọng như cần tiền tố trình duyệt hoặc chỉ hỗ trợ một phần chức năng.
- 5Với quyết định ảnh hưởng tới sản xuất, đối chiếu lại số phiên bản chính xác trên caniuse.com hoặc MDN, đặc biệt nếu tệp người dùng của bạn còn dùng trình duyệt phiên bản cũ.
Vì sao một tính năng có thể vừa "hỗ trợ" vừa cần điều kiện đi kèm
Rất nhiều tính năng web hiện đại không đi vào trình duyệt trong một lần duy nhất mà qua nhiều giai đoạn: trước tiên chạy sau một cờ thử nghiệm (flag) mà người dùng phải tự bật, sau đó chạy mặc định nhưng cần tiền tố nhà cung cấp như -webkit-, rồi cuối cùng mới chuẩn hóa không cần tiền tố. backdrop-filter là ví dụ điển hình: Safari hỗ trợ tính năng này từ bản 9 nhưng bắt buộc dùng tiền tố -webkit-backdrop-filter cho tới tận Safari 18 mới nhận cú pháp chuẩn, nên CSS cho người dùng Safari cũ vẫn nên khai báo cả hai. Một ví dụ khác là BarcodeDetector API, hiện chỉ chạy trên các trình duyệt nền Chromium và còn phụ thuộc hệ điều hành (có trên macOS, ChromeOS, Android nhưng thường không có trên Chrome desktop cho Windows), hoàn toàn không có trong Firefox hay Safari. Vì vậy bảng dữ liệu này cố tình tách riêng cột ghi chú thay vì chỉ hiện một dấu tích hay dấu gạch đơn giản, để bạn biết chính xác điều kiện cần đáp ứng trước khi đưa tính năng vào sản phẩm.
Baseline là gì và vì sao nó đáng chú ý hơn số phiên bản của từng trình duyệt riêng lẻ
Từ vài năm gần đây, nhóm phát triển web tại Google, Mozilla và các bên liên quan khác giới thiệu khái niệm Baseline: một tính năng được gắn nhãn Baseline khi nó đã được toàn bộ các trình duyệt chính hỗ trợ ổn định, nghĩa là an toàn để dùng trong sản phẩm mà không cần polyfill hay kiểm tra hỗ trợ riêng lẻ cho từng trình duyệt. Baseline có hai mức: "Newly available" nghĩa là mới đạt hỗ trợ đầy đủ trên cả bốn trình duyệt lớn, và "Widely available" nghĩa là đã đạt mức đó ổn định trong ít nhất ba mươi tháng, đủ lâu để phần lớn người dùng đã cập nhật trình duyệt lên phiên bản hỗ trợ. Cách đọc bảng dữ liệu ở trên gần giống tinh thần Baseline: nếu cả bốn cột đều hiện badge xanh lá, tính năng đó gần như chắc chắn dùng an toàn cho phần lớn tệp người dùng phổ thông; nếu có dù chỉ một cột đỏ hoặc vàng, cần cân nhắc kỹ đối tượng người dùng thực tế của sản phẩm trước khi quyết định.
Vì sao Safari thường là trình duyệt hỗ trợ chậm nhất với các API JavaScript mới
Đây là một khuôn mẫu hay gặp nhưng không phải quy luật tuyệt đối: các API mới thường xuất hiện trên Chrome trước tiên vì đội ngũ Chromium tích cực đề xuất và triển khai thử nghiệm các đặc tả mới, còn Safari — vốn phải đồng bộ với chu kỳ phát hành hệ điều hành của Apple thay vì phát hành độc lập như các trình duyệt khác — thường chậm hơn hoặc không triển khai các Web API liên quan tới phần cứng như BarcodeDetector, và bảng này vẫn ghi Safari chưa có requestIdleCallback (nên xác minh lại trên caniuse nếu bạn cần API này). Tuy vậy cũng có nhiều trường hợp ngược lại: Safari có :has() từ bản 15.4 trong khi Firefox phải tới bản 121, Safari có Web Share API trên macOS từ bản 12.1 trong khi Firefox desktop vẫn chưa bật, và Safari hỗ trợ Payment Request API cho Apple Pay từ bản 11.1 trong khi Firefox chưa bật mặc định. Điều này không có nghĩa Safari kém về mặt kỹ thuật, mà phản ánh triết lý thận trọng của Apple với việc mở rộng bề mặt API có thể ảnh hưởng tới quyền riêng tư hoặc bảo mật, cùng với ràng buộc lịch phát hành gắn liền với iOS và macOS. Với sản phẩm có tệp người dùng dùng nhiều thiết bị Apple, luôn kiểm tra kỹ cột Safari trước khi phụ thuộc vào một Web API mới.
Progressive enhancement: chiến lược thực tế khi tính năng chưa được hỗ trợ đều
Thay vì chờ một tính năng đạt hỗ trợ đầy đủ trên cả bốn trình duyệt rồi mới dùng, phần lớn đội ngũ frontend có kinh nghiệm áp dụng chiến lược tăng cường dần (progressive enhancement): viết mã sao cho trải nghiệm cơ bản vẫn hoạt động trên trình duyệt chưa hỗ trợ, còn trình duyệt đã hỗ trợ thì nhận thêm trải nghiệm nâng cao. Ví dụ cụ thể với container queries: viết CSS mặc định theo media query truyền thống dựa trên viewport, sau đó bọc phần container query trong khối @supports để chỉ áp dụng khi trình duyệt hỗ trợ, nhờ vậy Safari 15 trở về trước vẫn hiển thị bố cục hợp lý dù không có hiệu ứng theo kích thước container. Với JavaScript, kỹ thuật tương tự là kiểm tra sự tồn tại của API trước khi gọi, ví dụ if ("share" in navigator) trước khi dùng Web Share API, và chuẩn bị sẵn phương án dự phòng như sao chép link vào clipboard cho trình duyệt chưa hỗ trợ.
Vì sao bảng dữ liệu này cần được cập nhật định kỳ và giới hạn của một ảnh chụp nhanh
Trình duyệt phát hành phiên bản mới liên tục — Chrome và Firefox theo chu kỳ khoảng bốn tuần, Safari gắn với các bản beta và chính thức của macOS/iOS — nên bất kỳ bảng dữ liệu tĩnh nào cũng chỉ phản ánh đúng tình trạng tại thời điểm biên soạn chứ không tự động cập nhật theo thời gian thực như caniuse.com vốn được đồng bộ liên tục từ dữ liệu chính thức của các trình duyệt. Với những tính năng đang trong giai đoạn hoàn thiện đặc tả như CSS Anchor Positioning, khoảng cách hỗ trợ giữa các trình duyệt có thể thay đổi nhanh chỉ trong vài tháng. Vì lý do đó, bảng dữ liệu ở trên nên được xem như một điểm khởi đầu tra cứu nhanh cho những câu hỏi không đòi hỏi độ chính xác tuyệt đối, còn với quyết định ảnh hưởng trực tiếp tới trải nghiệm của hàng triệu người dùng sản phẩm thật, bước xác nhận lại trên caniuse.com hoặc MDN ngay trước khi triển khai vẫn là điều nên làm.
Những điểm dễ nhầm nhất trong bảng, rút ra từ lần rà soát tháng 9/2026
Khi rà soát lại bảng, một số mục trước đây ghi sai hoặc đã lỗi thời và đáng để lập trình viên lưu ý vì chúng cũng là những chỗ hay bị hiểu nhầm ngoài thực tế. Thứ nhất, AVIF trên Edge: nhiều người mặc định Edge có mọi thứ Chrome có vì cùng nền Chromium, nhưng Edge chỉ bật giải mã AVIF từ bản 121, muộn hơn Chrome 85 khoảng ba năm; nếu phục vụ AVIF mà không có WebP hoặc JPEG dự phòng qua thẻ picture, người dùng Edge cũ sẽ thấy ảnh hỏng. Thứ hai, backdrop-filter trên Safari: từ Safari 18 đã nhận cú pháp chuẩn, nhưng người dùng iOS và macOS cũ vẫn cần -webkit-backdrop-filter. Thứ ba, Payment Request trên Safari: không phải là không hỗ trợ, mà hỗ trợ từ Safari 11.1 với phương thức thanh toán Apple Pay; thẻ ngân hàng thông thường vẫn phải qua cổng thanh toán riêng. Thứ tư, color-mix() có trên Safari từ 16.2 chứ không phải 16.4. Thứ năm, CSS Anchor Positioning đã có trên Safari 26 và đang được triển khai trên Firefox, nên không còn là tính năng chỉ có trên Chromium.
Số phiên bản trong bảng áp dụng cho desktop, mobile cần đọc khác
Mọi số phiên bản trong bảng là bản desktop ổn định đầu tiên hỗ trợ. Với di động cần lưu ý hai điểm. Trên iOS và iPadOS, mọi trình duyệt (kể cả Chrome, Edge, Firefox và Cốc Cốc cho iPhone) từ lâu đều phải dùng engine WebKit của Apple, nên mức hỗ trợ trên iPhone gần như luôn đi theo cột Safari và phiên bản iOS, không theo cột Chrome; quy định này chỉ được nới ở một số thị trường như Liên minh châu Âu. Trên Android, Chrome và các trình duyệt nền Chromium cập nhật qua cửa hàng ứng dụng nên thường theo sát cột Chrome, nhưng WebView bên trong ứng dụng (như trình duyệt tích hợp trong Zalo hay Facebook) có thể chạy phiên bản khác. Cốc Cốc trên máy tính dùng nền Chromium nên thường tương đương cột Chrome ở phiên bản tương ứng, nhưng bảng này không có cột riêng cho Cốc Cốc. Nếu sản phẩm của bạn có nhiều người dùng vào từ trong ứng dụng mạng xã hội, hãy kiểm tra trên thiết bị thật.
Mẫu kiểm tra hỗ trợ trước khi dùng tính năng mới
Bảng giúp biết tính năng có tồn tại ở đâu, còn trong mã nguồn nên kiểm tra hỗ trợ ngay lúc chạy. Với CSS, dùng khối @supports: ví dụ @supports selector(:has(a)) để chỉ áp dụng quy tắc :has() khi trình duyệt hiểu nó, hoặc @supports (container-type: inline-size) cho container queries. Với backdrop-filter, khai báo -webkit-backdrop-filter trước rồi backdrop-filter sau, và đặt màu nền bán trong suốt đủ đậm để chữ vẫn đọc được khi hiệu ứng mờ không có. Với JavaScript, kiểm tra sự tồn tại trước khi gọi: if ("share" in navigator) cho Web Share, if ("BarcodeDetector" in window) cho quét mã vạch, typeof structuredClone === "function" cho structuredClone. Với ảnh, dùng thẻ picture với nguồn AVIF, sau đó WebP, cuối cùng là JPEG. Kiểm tra lúc chạy chính xác hơn bất kỳ bảng tĩnh nào, vì nó phản ánh đúng trình duyệt của từng người dùng.
Câu hỏi thường gặp (FAQ)
Dữ liệu trong bảng này được lấy từ đâu và có được cập nhật thường xuyên không?
Dữ liệu được biên soạn thủ công theo caniuse.com và MDN và rà soát lại lần cuối vào tháng 9/2026. Bảng không kết nối với nguồn dữ liệu trực tuyến nào, nên không tự cập nhật khi trình duyệt ra bản mới; những tính năng còn đang triển khai như CSS Anchor Positioning trên Firefox được ghi là cần xác minh trên caniuse thay vì đưa một số phiên bản có thể sai.
Vì sao tôi nên kiểm tra lại trên caniuse.com thay vì chỉ tin vào bảng này?
Vì caniuse.com được đồng bộ liên tục từ dữ liệu chính thức của các trình duyệt và bao gồm cả số liệu thị phần sử dụng theo khu vực, trong khi bảng ở đây là dữ liệu tĩnh biên soạn một lần. Với quyết định mang tính sản xuất, đặc biệt cần biết chính xác đến từng bản build, luôn xác nhận lại trên caniuse.com hoặc MDN.
Hỗ trợ một phần (badge màu vàng) nghĩa là gì?
Nghĩa là tính năng có chạy được trên trình duyệt đó nhưng kèm điều kiện, ví dụ cần tiền tố trình duyệt như -webkit-, chỉ hỗ trợ trên một số hệ điều hành (như BarcodeDetector trên Chrome), hoặc chỉ hỗ trợ một phần chức năng của đặc tả đầy đủ (như Payment Request trên Safari chỉ dùng được Apple Pay). Chi tiết điều kiện được ghi ngay dưới badge trong ô trình duyệt, và ghi chú chung nằm dưới tên tính năng.
Vì sao Safari thường hỗ trợ chậm hơn Chrome với các Web API mới?
Vì Safari phải đồng bộ chu kỳ phát hành với hệ điều hành của Apple thay vì phát hành độc lập, cùng với cách tiếp cận thận trọng hơn với các API có thể ảnh hưởng tới quyền riêng tư hoặc bảo mật. Đây là khuôn mẫu lặp lại với nhiều Web API liên quan tới phần cứng hoặc tương tác hệ thống.
Baseline trong web development nghĩa là gì?
Baseline là nhãn cho biết một tính năng đã được toàn bộ trình duyệt chính hỗ trợ ổn định, chia làm hai mức: Newly available (mới đạt đủ trên cả bốn trình duyệt) và Widely available (đã ổn định ít nhất ba mươi tháng). Tính năng đạt Baseline Widely available thường an toàn để dùng mà không cần polyfill.
Tôi có thể dùng một tính năng chưa được hỗ trợ đầy đủ trên cả bốn trình duyệt không?
Có thể, bằng chiến lược tăng cường dần: viết trải nghiệm cơ bản hoạt động ở mọi trình duyệt, sau đó bọc phần dùng tính năng mới trong @supports (với CSS) hoặc kiểm tra sự tồn tại của API (với JavaScript) để chỉ áp dụng trên trình duyệt đã hỗ trợ, còn trình duyệt chưa hỗ trợ vẫn nhận trải nghiệm cơ bản ổn định.
Vì sao BarcodeDetector API không có trên Firefox và Safari?
BarcodeDetector nằm trong một nhóm API Shape Detection do Google đề xuất, hiện chỉ được triển khai trên các trình duyệt nền Chromium. Firefox và Safari chưa công bố lộ trình triển khai API này, nên nếu cần quét mã vạch đa trình duyệt, giải pháp thực tế là dùng một thư viện JavaScript như ZXing thay vì API gốc.
Container queries khác gì so với media queries truyền thống?
Media query áp dụng style dựa trên kích thước viewport của toàn bộ trang, còn container query áp dụng style dựa trên kích thước của chính phần tử cha chứa nó, bất kể viewport rộng hay hẹp. Điều này giúp một component hiển thị đúng bố cục dù được đặt trong sidebar hẹp hay khu vực nội dung rộng trên cùng một trang.
Tại sao trang này không dùng luôn API của caniuse.com để lấy dữ liệu?
Để công cụ hoạt động hoàn toàn độc lập, không phụ thuộc vào dịch vụ bên ngoài và không có độ trễ tải dữ liệu qua mạng, dữ liệu được biên soạn sẵn ngay trong trang. Đánh đổi là dữ liệu không tự động cập nhật theo thời gian thực như bản gốc trên caniuse.com.
Tôi nên làm gì nếu tính năng cần dùng chỉ được hỗ trợ đầy đủ trên Chrome và Edge?
Trước tiên xác định tỷ lệ Chrome/Edge trong tệp người dùng thực tế của sản phẩm qua Google Analytics hoặc công cụ phân tích tương tự. Nếu tỷ lệ đủ cao và tính năng không phải chức năng lõi, có thể triển khai kèm phương án dự phòng cho trình duyệt khác theo chiến lược tăng cường dần thay vì chờ hỗ trợ đầy đủ.
Vì sao WebSockets và Web Workers không có ghi chú đặc biệt nào trong bảng?
Vì đây là những API đã tồn tại rất lâu, được toàn bộ trình duyệt hiện đại hỗ trợ đầy đủ từ nhiều năm trước, không còn vướng điều kiện đặc biệt nào. Chúng được giữ lại trong bảng như điểm tham chiếu cho những tính năng nền tảng đã ổn định hoàn toàn.
Danh sách năm mươi mấy tính năng này được chọn theo tiêu chí gì?
Ưu tiên các tính năng CSS và JavaScript hiện đại được lập trình viên tìm kiếm và hỏi nhiều nhất trong vài năm gần đây, kết hợp giữa tính năng đã ổn định lâu và tính năng mới đang trong giai đoạn hỗ trợ chưa đồng đều giữa các trình duyệt, để bảng vừa hữu ích cho tra cứu nhanh vừa phản ánh đúng những điểm cần cân nhắc khi quyết định dùng công nghệ mới.
Microsoft Edge có hỗ trợ ảnh AVIF không?
Có, từ Edge 121 (đầu năm 2024). Dù cùng nền Chromium, Edge bật AVIF muộn hơn Chrome (bản 85) khá lâu, nên nếu cần hỗ trợ Edge cũ hãy dùng thẻ picture với WebP hoặc JPEG dự phòng.
backdrop-filter trên Safari còn cần tiền tố -webkit- không?
Từ Safari 18, cú pháp chuẩn backdrop-filter đã hoạt động. Với Safari 9 đến 17, vẫn cần -webkit-backdrop-filter. Cách an toàn là khai báo cả hai dòng, dòng có tiền tố trước.
Safari có hỗ trợ Payment Request API không?
Có, từ Safari 11.1, nhưng chỉ với phương thức thanh toán Apple Pay. Vì vậy bảng ghi Safari là hỗ trợ một phần. Firefox chưa bật Payment Request mặc định.
Chrome trên iPhone có hỗ trợ giống cột Chrome trong bảng không?
Thường là không. Trên iOS, Chrome và các trình duyệt khác từ lâu dùng engine WebKit của Apple, nên mức hỗ trợ đi theo cột Safari và phiên bản iOS của máy. Bảng này ghi số phiên bản cho desktop.
Từ khóa liên quan
- kiểm tra hỗ trợ trình duyệt online
- caniuse tiếng việt
- browser compatibility checker
- css có hỗ trợ trên safari không
- tra cứu css browser support
- javascript api hỗ trợ trình duyệt nào
- css has hỗ trợ trình duyệt nào
- container query hỗ trợ browser
- backdrop filter safari
- view transitions api hỗ trợ
- baseline web features
- kiểm tra tính năng css mới
- web api hỗ trợ chrome firefox safari
- tra bảng tương thích mdn
- css nesting hỗ trợ trình duyệt
- progressive enhancement css
- polyfill javascript api mới
- công cụ tra cứu browser support miễn phí
- kiểm tra tương thích trình duyệt trước khi deploy
- danh sách css features hiện đại