Trình Tạo Slug URL

Slug URL là gì?

A slug is the human-readable, URL-safe path segment that identifies a page within a site. It sits at the tail of the URL and replaces what would otherwise be an opaque database identifier with a descriptive token. In https://example.com/blog/2026/my-awesome-post, the slug is my-awesome-post. Mechanically, a slug is the output of a deterministic transformation: take an arbitrary input string, strip everything that isn't allowed in a URL path segment, fold case, replace whitespace with a separator, and emit ASCII. The transformation is one-way in practice, you can't reliably reconstruct "My Awesome Post: Take Two!" from my-awesome-post-take-two: which is why slugs are stored alongside the original title, not in place of it.

Slug tốt chỉ sử dụng chữ cái thường, số và dấu gạch ngang. Chúng loại bỏ dấu, ký tự đặc biệt và khoảng trắng dư thừa. Điều này cải thiện cả SEO và trải nghiệm người dùng · công cụ tìm kiếm và con người có thể đọc URL và hiểu nội dung của trang.

Từ này đến từ đâu, các phòng tin thế kỷ XIX

Từ này có trước web một thế kỷ. Trong các xưởng đúc chữ thời Linotype, mỗi dòng chữ được đúc thành một dải kim loại duy nhất, một "slug", rộng khoảng ba mươi pica và nặng khoảng mười hai ounce chì. Thuật ngữ sau đó trượt sang chỉ định danh ngắn mà biên tập viên viết ở đầu một bài để dán nhãn nó qua sản xuất: một handle một hoặc hai từ như mayor-budget hoặc school-fire mà ký giả, thư ký tòa soạn và thợ in có thể dùng để tham chiếu đến bài mà không gõ tiêu đề đầy đủ. Hướng dẫn phong cách AP và các nhật báo lớn vẫn ghi lại cách dùng này.

Khi Movable Type, WordPress và tài liệu Django thuở đầu chấp nhận "slug" làm tên trường vào đầu thập niên 2000, họ mượn thuật ngữ tòa soạn nguyên si. Tài liệu Django gọi trường slug ít nhất từ bản phát hành 0.91 năm 2005, với định nghĩa nay kinh điển: một label ngắn chỉ chứa chữ cái, chữ số, gạch dưới hoặc gạch nối, thường dùng trong URL. Phép ẩn dụ rất đúng vì cả slug chì đúc và slug URL đều là token ngắn, riêng biệt và thân thiện máy chỉ về một thứ dài hơn.

RFC 3986 và tập ký tự không-dành-riêng

URL syntax is defined by RFC 3986 ("Uniform Resource Identifier (URI): Generic Syntax"), published January 2005 by Tim Berners-Lee, Roy Fielding and Larry Masinter, replacing RFCs 2396 and 2732. It is an STD 66 Internet Standard, the IETF's highest maturity tier, reserved for protocols of demonstrated stability and broad implementation. Section 2.3 of RFC 3986 defines the unreserved characters, the only characters that are guaranteed to be safe in any URI component without percent-encoding: A-Z, a-z, 0-9, hyphen, period, underscore, and tilde. That's sixty-six characters total. Everything else is either a reserved character (with structural meaning in some URI component) or "other", anything in the latter group must be percent-encoded if it appears in a URI.

Vì tập không-dành-riêng là tập duy nhất được đảm bảo đi vòng tròn sạch qua mọi parser URI từng được viết, các trình tạo slug hội tụ về pipeline gần như giống hệt: đưa ký tự alphabet về chữ thường, giữ chữ số, giữ gạch nối, thay khoảng trắng bằng một gạch nối duy nhất, và hoặc gỡ-hoặc-chuyển-tự mọi thứ khác. Gạch dưới, dấu chấm và dấu ngã về kỹ thuật được phép nhưng theo quy ước tránh trong slug, dấu chấm xung đột với phần mở rộng tệp, dấu ngã đọc như thư mục home trong quy ước URL cũ, và gạch dưới thua gạch nối vì lý do SEO sẽ bàn sau.

"Cool URIs Don't Change", Berners-Lee, 1998

Ghi chú phong cách năm 1998 của Tim Berners-Lee "Cool URIs Don't Change", host trên site W3C, là mảnh triết học slug được trích nhiều nhất từng viết. Câu mở đầu nổi tiếng: một cool URI là cái không thay đổi. Ghi chú sau đó đọc như một bài tranh luận chống các thiết kế URL ghi chi tiết triển khai phù du vào path. Các điều-không-nên được khuyến nghị đã hình thành thực hành slug suốt gần ba mươi năm: đừng đặt phần mở rộng công cụ viết vào URL, chúng tiết lộ triển khai và vỡ khi bạn di trú; đừng đặt trạng thái vào URL, trang thoát khỏi "hiện hành" nhưng URL không nên; đừng đặt tên tác giả, tác giả ra đi; đừng đặt ngày trừ khi ngày là cơ bản với tài nguyên; đừng đặt ID phiên, tham số query hay trạng thái đăng nhập vào URL kinh điển.

Slug, các từ mô tả, ngữ nghĩa, chữ-thường-gạch-nối-từ, đúng là điều được phép trong URI "cool". Mọi thứ khác là trang trí cấu trúc không nên rò vào địa chỉ. Thiết kế permalink của WordPress, SlugField của Django và to_param của Rails đều nội tâm hóa lời khuyên này: phát một URL là ý nghĩa của trang, không phải cơ chế cách nó được phục vụ.

Gạch nối thắng gạch dưới, và đó là tài liệu hóa

Trong cuộc phỏng vấn WebmasterWorld năm 2005, kỹ sư Google Matt Cutts nói rằng gạch nối được tokenizer của Google xem là phân cách từ, trong khi gạch dưới là nối từ. Vậy green-apples được đọc là hai token green và apples, trong khi green_apples được đọc là token duy nhất green_apples. Cho truy vấn "green apples", URL có gạch nối sẽ khớp kiểm tra từ khóa tiêu đề; URL có gạch dưới thì không. Cutts trở lại điều này năm 2007 trên blog của ông và trong video Google Webmaster Help năm 2011 trên YouTube ("Underscores vs. dashes in URLs"), tái khẳng định cùng lời khuyên và ghi nhận Google ở một thời điểm đã đánh giá đổi hành vi gạch dưới để cũng làm phân cách, nhưng đã không, vì điều đó sẽ phá quá nhiều URL hiện hữu cố ý dùng gạch dưới làm nối (__init__.py, tên hàm lập trình).

Trang hiện hành của Google "URL structure best practices for Google Search" khuyến nghị trực tiếp gạch nối: một URL như /green-dress.html hữu ích hơn /greendress.html, và bạn nên dùng gạch nối thay vì gạch dưới. Khuyến nghị được tài liệu hóa liên tục hơn hai mươi năm. Hiệu ứng nhỏ mỗi URL nhưng tích lũy trên một site hàng nghìn trang, và đổi gạch nối thành gạch dưới không có lợi, không có kịch bản SEO nào nơi gạch dưới thắng. Mọi hướng dẫn slug đáng tin đều kết thúc với cùng lời khuyên: hãy dùng gạch nối.

Chuẩn hóa Unicode, NFD bỏ dấu thế nào

Chuẩn Unicode định nghĩa hai cách mã hóa nhiều ký tự có dấu: tiền-soạn (một code point duy nhất, nơi é là U+00E9) và phân-rã (một chữ cái cơ sở theo sau bởi marker kết hợp, nơi é là U+0065 cộng U+0301, dấu sắc kết hợp). Giống nhau về thị giác, khác nhau từng byte. Unicode Technical Standard #15 định nghĩa bốn dạng chuẩn hóa, NFC, NFD, NFKC, NFKD, và để sinh slug, NFD là đòn bẩy. Nếu bạn lấy chuỗi đầu vào, chuẩn hóa nó về NFD, rồi gỡ mọi code point trong dải Unicode U+0300 đến U+036F (block Combining Diacritical Marks), bạn lấy lại chữ cái ASCII cơ sở. Café trở thành cafe, naïve trở thành naive, François trở thành Francois, niño trở thành nino, crème brûlée trở thành creme brulee.

NFD không gập các ký tự không phân rã được thành cơ-sở+marker. ß Đức (s cứng) không phân rã thành ss dưới NFD, nó đòi chuyển tự rõ ràng. ł Ba Lan (l có gạch) không phân rã thành l. ø Na Uy không phân rã thành o. þ Iceland (thorn) và ð (eth) cần bảng đối ứng. Trình duyệt hỗ trợ String.prototype.normalize() nguyên gốc từ khoảng 2015 (Chrome 34, Firefox 31, Safari 10), đó là lý do ngay cả tiện ích slugify JavaScript nhỏ cũng có thể làm việc gỡ dấu mà không cần thư viện.

Họ thư viện slugify, mỗi hệ sinh thái giao gì

django.utils.text.slugify() của Django ở trong framework Python từ đầu thập niên 2000. Nó đưa về chữ thường, gỡ ký tự không có trong [A-Za-z0-9_-], và thay khoảng trắng bằng gạch nối. Từ Django 1.9 (2015), một keyword allow_unicode=True chuyển sang chế độ Unicode-aware giữ chữ cái không-ASCII. Đây là triển khai tham chiếu mà mọi người sao chép. Trong Node.js, @sindresorhus/slugify của Sindre Sorhus là gói slugify được tải nhiều nhất trên npm, với hàng triệu lượt tải hàng tuần, tính năng gồm phân cách dễ đọc, các thay thế tùy biến (để bạn có thể ánh xạ & sang and, @ sang at), xử lý Unicode và chữ thường có nhận thức locale (I có chấm/không chấm Thổ Nhĩ Kỳ, ß → ss Đức). Cho người dùng Python không dùng Django, python-slugify của Val Neekman trên PyPI bọc thư viện chuyển tự unidecode và thêm hành vi riêng cho slug: cắt từ bằng regex, ký tự thay thế, độ dài tối đa, gỡ stopword.

Các hệ sinh thái khác theo cùng khuôn mẫu. PHP có cocur/slugify của Cocur trên Packagist, được plugin Laravel và Symfony dùng, và bản thân Symfony giao một AsciiSlugger trong symfony/string từ phiên bản 5.0. Ruby on Rails dùng String#parameterize, tích hợp trong ActiveSupport ít nhất từ Rails 1.0; gem friendly_id chồng theo dõi lịch sử và xử lý va chạm. Go có gosimple/slug với bảng locale cho hơn tám mươi ngôn ngữ. Rust có crate slug. Java có Apache Commons Text và slugify-jvm. Điều đáng chú ý là API hội tụ đến đâu: chuỗi vào, slug ra, với cùng một số ít tùy chọn, phân cách, độ dài tối đa, chữ thường, locale. Công cụ Absolutool ghi tên vào cùng họ nhưng chạy hoàn toàn trong trình duyệt, không thư viện cần cài.

WordPress: 43% web chạy pipeline này

WordPress là hệ thống phát slug lớn nhất trên web, nó cấp năng lượng cho khoảng 43% mọi website theo khảo sát W3Techs năm 2026, nên các quy ước slug của nó là quy ước slug của web cho phần lớn độc giả. Khi một post được lưu, WordPress tự sinh slug từ tiêu đề qua sanitize_title() (gọi sanitize_title_with_dashes() cho trường hợp viết lại mặc định): chữ thường, gỡ HTML, giải mã thực thể, thay khoảng trắng và phần lớn dấu câu bằng gạch nối, percent-encode ký tự nguy hiểm, gộp gạch nối liền kề, gỡ gạch nối đầu/cuối. Nếu kết quả va chạm với slug của post hiện hữu, WordPress thêm -2, -3, vân vân. Slug có thể sửa trong trình soạn post, một khi post được công bố, đổi slug phá mọi liên kết hiện hữu trừ khi biên tập đặt redirect. WordPress trong lịch sử không chuyển tự ký tự không-ASCII theo mặc định; nó percent-encode chúng, tạo ra các URL Cyrillic xấu nổi tiếng như %D0%BF%D1%80%D0%B8... mà các plugin như Cyr-To-Lat được viết để sửa.

Vượt khỏi Latin: chuyển tự cho Cyrillic, CJK, Arabic

NFD chỉ xử lý các ký tự phân rã thành cơ-sở-ASCII + marker kết hợp. Cho script không-Latin, pipeline slug cần chuyển tự, một ánh xạ từ mỗi ký tự không-Latin sang tương đương script Latin của nó. Thư viện Python kinh điển là unidecode, ban đầu là port của Text::Unidecode Perl của Sean M. Burke từ năm 2001, ánh xạ gần như mọi ký tự trong Basic Multilingual Plane sang chuỗi ASCII "đoán tốt nhất": Москва → Moskva, Αθήνα → Athena. Fallback CJK là phần gây tranh cãi: unidecode dùng pinyin Quan Thoại cho mọi ký tự CJK vì tiếng Trung có độ phủ ký tự CJK lớn nhất, tạo ra romanization vô lý cho tiếng Nhật (東京 → Dong Jing trong pinyin, không phải Tokyo). Công cụ riêng cho tiếng Nhật như pykakasi làm việc chuyển kanji + kana sang rōmaji sạch. Thư viện International Components for Unicode (ICU), do Unicode Consortium và IBM bảo trì, cung cấp API Transliterator với các bộ quy tắc có tên như Russian-Latin/BGN, Greek-Latin/UNGEGN, và Han-Latin triển khai chuẩn romanization chính thức. Công cụ Absolutool đứng ở đầu nhẹ: gập diacritic Latin qua NFD và bỏ mọi cái khác. Người dùng muốn slug tiêu đề Nga hay Trung có thể chạy bước chuyển tự riêng trước khi dán văn bản.

Giới hạn độ dài URL, quy tắc 2000 ký tự đến từ đâu

Không có giới hạn độ dài nào do RFC 3986 đặc tả, cú pháp URI không bị chặn. Mọi giới hạn là thực dụng. Internet Explorer trong lịch sử giới hạn URL ở 2.083 ký tự (giới hạn cứng tích hợp trong engine Trident), đó là gốc của quy tắc kinh nghiệm "2.000 ký tự" được trích nhiều. Chrome, Firefox, Safari và Edge hiện đại hỗ trợ URL đến khoảng 64.000 đến 100.000+ ký tự trong thanh địa chỉ. LimitRequestLine của Apache mặc định 8.190 byte cho cả dòng request; large_client_header_buffers của nginx mặc định 8 KB; IIS mặc định 16.384 byte cho URL và 4.096 cho query string. RFC 9110 (HTTP/1.1, 2022) khuyến nghị ở §4.1 rằng server "nên có khả năng xử lý URI dài 8.000 octet hoặc dài hơn" nhưng không đi xa đến mức áp đặt giới hạn trên. Cho slug, điều quan trọng là chúng theo quy ước ngắn, ba đến bảy từ, ba mươi đến sáu mươi ký tự, vì SEO và khả năng chia sẻ. John Mueller của Google đã nói trong nhiều Webmaster Hangout rằng độ dài URL tự nó không phải tín hiệu xếp hạng, nhưng URL dài có thể bị cắt trong snippet kết quả tìm kiếm, hại tỉ lệ click, và trông không chuyên nghiệp trong chia sẻ xã hội. Phần lớn trình tạo slug phơi tùy chọn độ dài tối đa vì lý do này; cái này mặc định không giới hạn và để bạn đặt trần.

Gỡ stopword: dày đặc và ngữ pháp

Nhiều thư viện slugify cung cấp gỡ stopword tùy chọn, bỏ các từ ngắn phổ biến (a, an, the, of, is, and, or, to, in, for, on) trước khi ráp slug. Lý do là chúng không thêm tín hiệu SEO và làm phồng URL. Vậy "The Best Way to Make a Cup of Tea" trở thành best-way-make-cup-tea (5 token, 24 ký tự) thay vì the-best-way-to-make-a-cup-of-tea (10 token, 35 ký tự). Đánh đổi: ngắn hơn và dày hơn, nhưng có sự sụp đổ ngữ pháp đôi lúc (how-to-be-good bị tước thành how-good mất nghĩa) và rủi ro gỡ các từ thực sự mang ý định (art-of-war tước thành art-war). WordPress không gỡ stopword theo mặc định, đó là hành vi plugin opt-in, và phần lớn trình tạo slug hiện đại để nó tắt mặc định và đề xuất như một ô tích. Yoast SEO cho WordPress đánh dấu một slug chứa stopword là khuyến nghị nhỏ chứ không phải lỗi. Trình tạo này không tự động gỡ stopword, lý do là biên tập biết ý định tiêu đề tốt hơn một danh sách từ tĩnh. Nếu bạn muốn thấy chúng đi, hãy sửa đầu ra trực tiếp.

Va chạm slug, CMS làm gì khi hai post chia sẻ một tiêu đề

Khi hai post tự sinh cùng slug, "My Post" và "My-Post!" đều tạo ra my-post, hệ thống phải giải xung đột. Các chiến lược phổ biến nhất: hậu tố số (my-post-2, my-post-3), dự đoán được, không bao giờ va chạm, nhưng hậu tố không mang khác biệt ngữ nghĩa nào; tiền tố ngày (2026-04-27/my-post), hoạt động tốt cho nội dung blog và là mặc định trong Jekyll, Hugo và phần lớn site tin tức; hậu tố tác giả (my-post-jane), được Medium và blog đa-tác-giả dùng; hậu tố hash ngẫu nhiên (my-post-a3f9), được Stack Overflow, Notion và hệ thống shortlink dùng, đánh đổi tính dễ đọc của con người để có duy nhất đảm bảo; hoặc sửa thủ công lúc công bố, sạch về biên tập nhưng hiếm khi là mặc định vì điều đó cắt luồng. Lựa chọn thực dụng cho phần lớn CMS là hậu tố số với sửa thủ công làm lối thoát. Permalink tiền tố ngày phổ biến cho nội dung neo theo thời gian nơi ngày là thông tin có ý nghĩa.

Tác động SEO, slug là tín hiệu nhỏ nhưng thấy được

Tài liệu xếp hạng của Google liệt cấu trúc URL là tín hiệu xếp hạng nhỏ, nội dung trang, backlink, tín hiệu tương tác người dùng và độ tươi đều mang trọng số nhiều hơn. Nhưng từ trong URL có đóng góp, và đóng góp một cách thấy được. Các từ trong slug xuất hiện trong dòng URL của snippet SERP dưới tiêu đề, ảnh hưởng tỉ lệ click ngay cả khi bản thân slug không được xếp hạng. Các từ trong slug có thể xuất hiện in đậm trong SERP nếu chúng khớp truy vấn người dùng, trọng số thị giác bổ sung. Văn bản neo của liên kết nội bộ và bên ngoài thường mặc định là URL khi không có văn bản link nào được cung cấp, nên một slug ngữ nghĩa trở thành văn bản link và mang từ khóa của nó qua equity của liên kết đến. Các bài kiểm thử A/B ở các nhà xuất bản nhất quán cho thấy slug mô tả tăng CTR theo phần trăm một-chữ-số so với ID mờ đục. Nghiên cứu yếu tố xếp hạng năm 2020 của Backlinko (1,18 triệu SERP được phân tích) tìm thấy URL ngắn vượt nhẹ URL dài ở đỉnh SERP.

Có một ngoại lệ với trực giác "nhiều từ khóa = tốt hơn": nhồi từ khóa. Cập nhật Exact-Match Domain (EMD) tháng 9 năm 2012 đã giảm cụ thể tín nhiệm cho các domain và slug exact-match chất lượng thấp (cheap-life-insurance.com/buy-cheap-life-insurance), và Google đã tiếp tục giảm giá nhồi từ khóa trong URL từ đó. Nhận định 2026: sự hiện diện từ khóa trong slug hỗ trợ chừng mực; nhồi từ khóa hại. Lợi ích SEO lớn nhất từ slug là không thay đổi nó sau công bố. Liên kết đến tích lũy về một URL. Authority trang cộng dồn ở mức URL. Một redirect 301 giữ phần lớn nhưng không tất cả equity link, và chỉ khi biên tập thực sự đặt redirect, nhiều người không. Lời khuyên "Cool URIs Don't Change" của Berners-Lee có hệ quả SEO trực tiếp: mỗi lần đổi slug, ngay cả với redirect, tốn một lượng nhỏ authority cần thời gian để khôi phục.

Thực hành tốt nhất SEO cho slug

• Giữ slug ngắn (3-5 từ là lý tưởng)
• Tích hợp các từ khóa mục tiêu
• Sử dụng dấu gạch ngang, không phải dấu gạch dưới (Google xử lý dấu gạch ngang như dấu phân cách từ)
• Loại bỏ các từ dừng (cái, là, và, v.v.) khi chúng không thêm gì
• Chỉ sử dụng chữ thường
• Tránh thay đổi slug sau khi xuất bản (hoặc thiết lập chuyển hướng)
• Hãy gỡ hoặc chuyển tự ký tự không-ASCII trừ khi nền tảng của bạn xử lý IRI sạch qua analytics, chia sẻ xã hội và client email.
• Tránh ngày trừ khi ngày là cơ bản với tài nguyên; tránh phần mở rộng tệp, ID phiên, tên tác giả và từ trạng thái.

Câu hỏi thường gặp

Có hỗ trợ ký tự có dấu không?

Có. Trình tạo sử dụng chuẩn hóa Unicode (NFD) để loại bỏ dấu. Ví dụ, « cafe » vẫn là « cafe » trong khi « café » cũng trở thành « cafe ». Điều này đảm bảo slug sạch, ASCII thuần.

Nên dùng dấu gạch ngang hay dấu gạch dưới?

Dấu gạch ngang được khuyến nghị cho SEO. Tài liệu chính thức của Google xác nhận rằng dấu gạch ngang trong URL được xử lý như dấu phân cách từ, trong khi dấu gạch dưới không được. Vì vậy « bai-viet » được đọc như hai từ, trong khi « bai_viet » chỉ tạo thành một.

Emoji và ký hiệu thì sao?

Emoji không nằm trong tập ký tự không-dành-riêng của URL, và NFD không phân rã chúng, chúng không có tương đương Latin. Trình tạo này bỏ chúng. Các công cụ khác percent-encode emoji (biến một ký tự đơn thành chuỗi dài như %F0%9F%94%A5), về kỹ thuật thì chạy trong trình duyệt hiện đại nhưng tạo URL không đọc được trong analytics, chia sẻ xã hội và preview email. Phần lớn hướng dẫn slug khuyến nghị bỏ hẳn emoji; nếu bạn muốn giữ chúng, hãy percent-encode chúng phía trước bước slug.

Có slug được tiêu đề Nga, Trung, hay Arabic không?

Không một mình. NFD chỉ gập ký tự có dấu trong script Latin, nó không thể chuyển tự script Cyrillic, Hy Lạp, Arabic, Hebrew hay CJK sang Latin. Dán một tiêu đề Nga hay Trung vào công cụ này sẽ bỏ các ký tự đó và tạo slug rỗng hoặc gần rỗng. Quy trình đúng là chạy bước chuyển tự trước, unidecode của Python, gói npm transliteration của JavaScript, hoặc các quy ước romanization của Wikipedia, và dán kết quả romanized vào đây. Cho tiếng Nhật cụ thể, hãy dùng công cụ kana-aware như pykakasi: trình chuyển tự CJK chung áp dụng pinyin Quan Thoại và tạo Dong Jing cho 東京 thay vì Tokyo.

Nếu tôi cần đổi slug sau công bố thì sao?

Hãy đặt redirect 301 từ URL cũ sang URL mới trước khi đổi slug. Một 301 ("Moved Permanently") giữ phần lớn equity link đã tích lũy về URL cũ và bảo crawler và trình duyệt cập nhật bookmark. Không có redirect, mọi liên kết đến hiện hữu sẽ vỡ và bạn mất authority trang mà các liên kết đó đại diện. Ngay cả với redirect, bạn mất một lượng nhỏ equity cần vài tuần hay vài tháng để khôi phục. Châm ngôn của Berners-Lee, cool URI không đổi, một phần là thẩm mỹ, một phần là sự thật SEO: mỗi lần đổi slug tốn một thứ gì đó, nên đáng làm slug đúng từ lần đầu.

Có độ dài slug khuyến nghị không?

Quy ước là ba đến bảy từ, khoảng ba mươi đến sáu mươi ký tự. Đủ dài để mô tả, đủ ngắn để snippet SERP của Google không cắt nó và con người có thể nắm chủ đề trong nháy mắt. Không có tối đa kỹ thuật cứng, RFC 3986 không đặc tả và trình duyệt hiện đại xử lý URL đến hàng chục nghìn ký tự, nhưng Apache, nginx và IIS áp đặt trần thực dụng trong dải kilobyte, và quy tắc kế thừa "2.000 ký tự" của Internet Explorer vẫn được trích như trần cross-platform an toàn. Tùy chọn Độ Dài Tối Đa ở đây để bạn đặt trần đầu ra; đặt nó về 0 nghĩa là không giới hạn.

Văn bản của tôi có được lưu hoặc gửi đi đâu không?

Không. Việc biến đổi chạy hoàn toàn trong trình duyệt dùng phương thức String.prototype.normalize() tích hợp của JavaScript (hỗ trợ từ Chrome 34, Firefox 31, Safari 10, khoảng 2015). Không gì được upload, không API nào được gọi, không log nào được viết. Bạn có thể kiểm chứng bằng cách mở tab Network của DevTools khi sinh slug, không có request đi ra. Trang an toàn cho slug dẫn xuất từ tiêu đề chưa công bố, tài liệu nội bộ, post nháp hay bất kỳ nội dung nào bạn không muốn rời khỏi thiết bị của mình.

Công cụ liên quan