Shift-JIS Encoder/Decoder

Show Shift-JIS (CP932) byte sequences for Japanese text

Encode Japanese text to Shift-JIS (CP932) byte sequences shown as hex, or decode Shift-JIS hex bytes back to text. Handles single-byte ASCII and half-width katakana plus two-byte kanji, runs locally in your browser, and flags characters outside the repertoire. It runs free in your browser on Gera Tools, with nothing uploaded.

Last updated Source: Gera Tools

What is Shift-JIS?

Shift-JIS is a widely used Japanese character encoding. The Windows variant, CP932, is what most files and systems mean by Shift-JIS. It mixes single-byte and two-byte characters in one stream, which is why it needs lead and trail byte ranges.

Shift-JIS is a long-standing Japanese character encoding; in practice most files labelled Shift-JIS use the Windows code page CP932. It mixes one-byte and two-byte characters in a single stream. This tool encodes Japanese text into Shift-JIS hex bytes and decodes Shift-JIS hex back into text.

How it works

ASCII and half-width katakana occupy a single byte. Every other character — kanji, hiragana, full-width katakana, full-width punctuation — is two bytes: a lead byte in 0x810x9F or 0xE00xFC, followed by a trail byte in 0x400xFC (skipping 0x7F). A decoder distinguishes the two cases by inspecting whether the current byte falls in a lead-byte range.

To stay faithful to the real CP932 table, the tool enumerates every valid single byte and lead/trail pair, decodes each with the browser’s native Shift-JIS decoder, and records the resulting character-to-bytes mapping. Encoding looks each character up in that map; decoding runs the hex bytes through the native decoder directly.

Byte layout at a glance

Character classBytesLead byte rangeTrail byte range
ASCII (0–127)1
Half-width katakana10xA1–0xDF
Kanji (JIS X 0208)20x81–0x9F or 0xE0–0xFC0x40–0xFC (not 0x7F)

The two-byte lead ranges intentionally avoid ASCII territory (0x00–0x7F) so a decoder can determine from the first byte alone whether a character is one or two bytes, without needing to look backwards. The trail byte range, however, can overlap with ASCII, which is the source of the parsing pitfall described below.

A concrete encoding example

The word 日本語 (nihongo, Japanese language) encodes to:

  • 日 → 93 FA
  • 本 → 96 7B
  • 語 → 8C EA

Full sequence as hex: 93 FA 96 7B 8C EA — six bytes for three kanji. Contrast with UTF-8, where the same three characters each take three bytes, totalling nine bytes.

The trail-byte trap

Because trail bytes can fall in the range 0x400x7E, which overlaps with ASCII printable characters, naive processing of a Shift-JIS byte stream can confuse a trail byte for an independent ASCII character. For example, if a two-byte sequence has a trail byte of 0x5C, a naive decoder might interpret 0x5C as an ASCII backslash and misparse everything that follows. This is the reason legacy Windows Japanese software sometimes showed garbled backslashes in file paths.

Always decode Shift-JIS using the full lead/trail logic, never byte by byte.

When to use this tool

  • Debugging legacy Japanese file formats (old game ROMs, CMS exports, EDI files) that use Shift-JIS internally.
  • Verifying byte sequences shown by a hex editor match the expected Japanese text.
  • Writing code that needs to handle Shift-JIS and you want to inspect what bytes a specific string produces before writing the conversion routine.
  • Checking whether a character has a Shift-JIS representation before including it in a system that cannot accept UTF-8.

Notes on scope

Shift-JIS predates emoji and many rare kanji outside the JIS X 0208 set, so modern symbols will be flagged as unmapped. Use UTF-8 for any new system that needs the full Unicode range. Shift-JIS remains practically relevant for interoperating with Japanese legacy systems, older databases, and file formats that pre-date the UTF-8 transition.