Fix KDP Garbled Text Before Uploading the Manuscript

An abstract editorial 3D still life illustrating Fix KDP Garbled Text Before Uploading the Manuscript

When a manuscript looks garbled before a KDP upload, do not save over the damaged-looking document. Preserve the original bytes first. The specimen for this article was one Japanese text file encoded in Shift_JIS. Reading those bytes incorrectly as UTF-8 produced 18 replacement characters. Reading the same file as Shift_JIS and saving the correct text to a separate UTF-8 copy produced a match at all 10 representative positions and for the total character count.

The starting point was the original Shift_JIS file. The operation was to compare an incorrect UTF-8 decode with the correct Shift_JIS decode, then save only the correct result as a new UTF-8 file. The measured values were 18 replacement characters on the wrong path and 10 out of 10 matching checkpoints on the correct path. The rollback point was the untouched Shift_JIS original.

This Stage 4 result is partial. It did not reproduce a garbled state in the rune Studio interface or test overwriting from that state. It also did not upload the manuscript to KDP or inspect the result on Kindle devices.

Garbled Text and Unconvertible Characters Are Different

Garbled text usually means that valid stored bytes were interpreted with the wrong character encoding. An unconvertible character is different: the character exists in the document but cannot be represented by the selected output encoding. A KDP rendering problem can also arise later from EPUB generation, CSS, fonts, images, or device behavior.

The 18 replacement characters in this test therefore do not prove that 18 source characters were permanently lost. They describe the result of one deliberately incorrect decode. Correct the read encoding first, then inspect output-encoding limitations as a separate step.

A Product-Independent Recovery Procedure

Preserve the source

Duplicate the original file. Use one copy for diagnosis and keep the other unchanged as the rollback point. Never save a visibly garbled decode over the only source copy.

Compare candidate decodes

Use information about the authoring application or previous export settings to select plausible encodings. Open separate copies with each candidate and compare the same title characters, punctuation, kanji, and symbols. In this specimen, the UTF-8 interpretation contained 18 replacement characters, while the Shift_JIS interpretation matched the expected text at 10 representative positions and in total length.

Save the verified text as a new UTF-8 file

Only the correctly decoded text should become the UTF-8 handoff copy. Keep a distinct filename, then compare its key positions and character count with the verified text. The original remains available if any discrepancy appears.

Inspect unconvertible characters separately

Emoji, platform-dependent symbols, and private-use characters may still be unsuitable for a legacy output encoding even after the text is decoded correctly. Replace those characters deliberately or choose an output encoding that can represent them. Keeping this step separate makes every textual change traceable.

Validate the KDP deliverable later

A correct local UTF-8 file does not prove KDP acceptance or rendering. Amazon KDP accepts EPUB manuscripts and recommends checking them with Kindle Previewer. Generate the EPUB and inspect navigation, page breaks, writing direction, images, and font substitution as a separate delivery test.

What rune Studio Provides

rune Studio supports UTF-8, UTF-8 with BOM, Shift_JIS, EUC-JP, ISO-2022-JP, UTF-16LE, UTF-16BE, and related fallback handling. It checks a BOM first, then applies automatic detection and Japanese encoding candidates. The encoding and line-ending settings can be changed from the status bar.

The application also marks contiguous ranges of Unicode characters that cannot be represented by the selected output encoding. If such characters remain, manual saving produces a warning, autosave pauses, and a notification appears.

Those are Stage 3 product capabilities. The Stage 4 test for this article established only the two decoding results and the matching UTF-8 copy. It did not capture the interface warning, red marking, or autosave pause and resume.

Supporting Evidence and Its Limit

A separate shared specimen read the same Japanese text as 39 characters in UTF-8, Shift_JIS, and EUC-JP. UTF-16LE and UTF-16BE copies included a line ending and measured 40 characters. The UTF-8 specimen also matched the tab setting.

That evidence supports basic multi-encoding handling. It does not establish a successful KDP upload, automatic conversion by another application, or safe overwriting from a garbled interface state.

Scope Compared with Nearby Articles

STUDIO-523 is about choosing an editor for mixed-encoding work. STUDIO-448 follows characters that disappear during EPUB conversion. Other KDP articles address layout previews or broken image paths.

This article has a narrower job: recover a pre-upload manuscript by protecting the original Shift_JIS bytes, selecting the correct decode, and producing a separately verified UTF-8 copy. It does not treat every EPUB or Kindle display defect as an encoding problem.

Safe Completion Criteria

The recovered file is ready for the next step when:

The local result remains partial. The verified UTF-8 copy is usable within the measured boundary, while rune Studio overwrite behavior and the final KDP result remain unverified.

If one editing environment for encoding detection and unconvertible-character checks would help, review the current Mac scope on the rune Studio product page.