Trong những năm 1990, nhiều máy chủ chuyển tiếp email trên internet chỉ có thể xử lý ASCII 7-bit. Shift_JIS và EUC-JP, là mã hóa 8-bit, có nguy cơ hỏng dữ liệu khi đi qua các tuyến đường như vậy. ISO-2022-JP giải quyết vấn đề này như mã hóa "7-bit sạch" nơi tất cả byte nằm trong phạm vi 7-bit (0x00-0x7F). Sách lịch sử internet bao gồm sự phát triển của mã hóa ký tự email.

Cơ chế hoạt động bằng cách sử dụng chuỗi thoát ESC $ B (0x1B 0x24 0x42) để chuyển sang chế độ tiếng Nhật JIS X 0208, và ESC ( B (0x1B 0x28 0x42) để quay lại chế độ ASCII. Mỗi ký tự tiếng Nhật được biểu diễn bằng 2 byte, trong khi ký tự ASCII sử dụng 1 byte tiêu chuẩn. Cơ chế chuyển đổi chế độ này cho phép văn bản tiếng Nhật và tiếng Anh cùng tồn tại trong một luồng byte duy nhất.

Hệ thống email hiện đại hỗ trợ mã hóa 8-bit như tiêu chuẩn, và với Content-Transfer-Encoding của MIME hỗ trợ Base64 và Quoted-Printable, UTF-8 đã trở thành chuẩn. Tuy nhiên, ISO-2022-JP vẫn được sử dụng trong một số tập đoàn và cơ quan chính phủ Nhật Bản để tương thích với hệ thống mail cũ. Dịch vụ email nhà mạng di động tại Nhật Bản sử dụng ISO-2022-JP làm tiêu chuẩn trong nhiều năm.

Một vấn đề phổ biến là "mojibake" (văn bản lỗi). Khi email ISO-2022-JP được hiểu là UTF-8, hoặc khi chuỗi thoát bị cắt ngắn giữa luồng, các ký tự không thể hiểu xuất hiện. Điều này thường do header Content-Type: text/plain; charset=ISO-2022-JP không chính xác. Sách cơ bản giao thức email giải thích chi tiết kỹ thuật.

So với Shift_JIS và EUC-JP, ISO-2022-JP có chi phí từ chuỗi thoát nhưng có lợi thế là 7-bit sạch. Shift_JIS chủ yếu được sử dụng trong môi trường Windows, EUC-JP trong môi trường UNIX, và ISO-2022-JP dành riêng cho email. Ngày nay, cả ba đang được thay thế bởi UTF-8.

Từ góc độ đếm ký tự, ISO-2022-JP tăng số byte do chuỗi thoát. Ví dụ, chuỗi 5 ký tự "こんにちは" cần 16 byte trong ISO-2022-JP (bao gồm chuyển đổi chế độ), so với 15 byte trong UTF-8 và 10 byte trong Shift_JIS. Hiểu sự khác biệt số byte giữa các mã hóa là quan trọng khi xem xét giới hạn kích thước email.