Cơ chế mã hóa rất đơn giản. Ký tự mục tiêu được chuyển đổi thành chuỗi byte UTF-8, và mỗi byte được biểu diễn dưới dạng % cộng hai chữ số thập lục phân. Ví dụ, khoảng trắng trở thành %20 (0x20), và ký tự tiếng Nhật "あ" là 3 byte trong UTF-8 (0xE3, 0x81, 0x82), tạo ra %E3%81%82. RFC 3986 quy định rằng tất cả ký tự ngoại trừ ký tự không dành riêng (A-Z, a-z, 0-9, -, _, ., ~) phải được percent-encode.

Trong thực tế, trình duyệt tự động áp dụng percent-encoding khi gửi truy vấn tìm kiếm và dữ liệu biểu mẫu. JavaScript cung cấp encodeURIComponent() cho mã hóa và decodeURIComponent() cho giải mã. Trong khi đó, encodeURI() nhắm vào toàn bộ URL và không mã hóa các ký tự dành riêng như / hoặc ?. Sử dụng sai hai hàm này có thể làm hỏng URL hoặc tạo ra lỗ hổng bảo mật.

Một quan niệm sai lầm phổ biến là nhầm lẫn percent-encoding với HTML entity (như &). Percent-encoding dành riêng cho URL, trong khi HTML entity escaping phục vụ mục đích khác với cú pháp khác. Cũng lưu ý rằng khi xử lý URL quốc tế hóa, trình duyệt hiển thị URL đã giải mã trong thanh địa chỉ, nhưng HTTP request thực tế gửi URL đã mã hóa.

Một khái niệm liên quan là mã hóa Base64, nhưng chúng phục vụ mục đích khác nhau. Percent-encoding biểu diễn an toàn các ký tự riêng lẻ trong URL, trong khi Base64 chuyển đổi dữ liệu nhị phân thành định dạng văn bản. Ngoài ra, trong định dạng application/x-www-form-urlencoded, khoảng trắng được biểu diễn dưới dạng + thay vì %20, minh họa các biến thể phụ thuộc ngữ cảnh.

Từ góc độ đếm ký tự, percent-encoding tạo ra sự chênh lệch giữa số ký tự gốc và độ dài byte URL. Một ký tự tiếng Nhật chiếm 3 byte trong UTF-8 và mở rộng thành 9 ký tự (%XX%XX%XX) sau percent-encoding. Khi xem xét giới hạn độ dài URL (khoảng 2.000 ký tự trong hầu hết trình duyệt), điều quan trọng là ước tính tham số truy vấn chứa ký tự không phải ASCII sẽ dài bao nhiêu.