All Tools View Categories About Contact Privacy

Log Encoding Converter

Repair mojibake and transcode log text between UTF-8, ANSI, Latin-1 and UTF-16.

Runs entirely in your browser — logs never leave this page.
Tip: text input repairs garbled display text; hex input transcribes exact byte data.

About Log Encoding Converter

When a log file comes off an old Windows box or a legacy daemon, the bytes are rarely what they look like on screen. Text that reads é instead of é, files that open as gibberish in a UTF-8 reader, and exports that refuse to paste cleanly into modern dashboards are all symptoms of one thing: an encoding mismatch nobody recorded. Log Encoding Converter makes those bytes honest again — without installing iconv, writing a Python one-liner, or guessing at a hex dump by eye.

Paste the text or hex bytes, tell the tool what encoding they are actually in, and it rebuilds the original bytes and re-reads them in the encoding you want to output. The classic mojibake case — text that was written in UTF-8 but displayed as ANSI — is a two-click fix: source ANSI, target UTF-8, Convert. The reverse direction works too: encode clean Unicode text down into Windows-1252, ISO-8859-1 or UTF-16 bytes for a system that only understands the older encoding, including the Windows-1252-specific characters in the 0x80–0x9F range (curly quotes, em dash, euro sign) that a naive Latin-1 mapping would get wrong.

Text input repairs display garbling; hex input lets you transcode data exactly, including bytes that contain NUL or control characters that a text editor would otherwise drop or corrupt. A byte-order-mark option and full hex view cover the fiddly cases, and UTF-16 little- and big-endian are both supported — useful for Windows Event Log exports and PowerShell transcripts, which default to UTF-16.

This is the kind of tool you reach for once a shift and forget about, until the next support ticket arrives with a log attachment full of question marks and diamonds. Everything runs in the browser with no uploads, so it is safe to paste production data straight from an incident.

Features

  • Four families: UTF-8, ANSI/Windows-1252, ISO-8859-1 and UTF-16 (LE/BE).
  • Text or hex input: paste characters to repair mojibake, or exact bytes to transcode.
  • Auto-detection: BOM sniffing plus a UTF-8 validity check with ANSI fallback.
  • Mojibake repair: decode ANSI-read UTF-8 (or any similar mismatch) in one click.
  • Accurate Windows-1252 mapping: the 0x80–0x9F control-code range (smart quotes, em dash, euro sign, trademark symbol) encodes to its real single byte instead of falling back to ?.
  • Hex output: see every byte you are going to ship.
  • Byte-order mark: strip on input, optionally add on output.
  • Byte + character counts: confirm the conversion did what you expect.
  • Copy / download / print: export the result as text or a PDF.
  • Local processing: nothing is uploaded, so pasted incident logs stay on your machine.

How to Use

  1. Paste your log. Enter the garbled or foreign-encoded text, or the hex bytes if you have them (for example from xxd or a hex editor).
  2. Pick the input form. Text for characters you copied out of a viewer, Hex for raw byte values you already have.
  3. Choose the source encoding. The encoding the input currently represents; Auto detects it for hex by checking for a BOM and then testing UTF-8 validity.
  4. Pick the target encoding and form. Where you want to end up, as readable text or as raw hex bytes.
  5. Convert. The repaired or transcoded value appears with byte and character counts so you can sanity-check the result.
  6. Copy, download or print. Take the result into your tooling, save it as a .txt file, or export a PDF for a ticket or report.

Examples

Example 1 — Repair ANSI mojibake. A log viewer shows Résumé as Résumé garbled. Paste the garbled text, set source ANSI, target UTF-8 and Text output — the original characters come back cleanly.

Example 2 — Ship UTF-16 bytes. A backend expects UTF-16LE with a BOM. Paste the UTF-8 text, choose Hex output with target UTF-16LE and the BOM option on, and copy the exact byte string for your fixture.

Example 3 — Read a legacy export. An old daemon writes ISO-8859-1. Feed its bytes as hex with source Latin-1 and target UTF-8, and every accented character converts to the encoding your pipeline expects.

Example 4 — Verify a file on disk. Dump the first line of a log as hex with xxd, paste it here with Auto source and Text output. The tool decodes it and confirms what encoding the file really uses.

Example 5 — Control characters intact. A metric line contains embedded bytes. Transcode via hex input and hex output so no encoding round-trip silently mangles the 0x00s and control bytes.

Example 6 — Curly quotes to Windows-1252. A message copied from a Word document contains a right single quotation mark. Encoding it as ANSI now produces the correct single byte 0x92 instead of a lossy ?, so downstream systems that expect real Windows-1252 bytes see the right character.

Benefits

  • Fixes garbled logs instead of binning them or re-requesting the export.
  • One tool, all four families — no separate converters per encoding.
  • Exact byte control with hex input and output, including NUL and control bytes.
  • True Windows-1252 fidelity for the special characters that plain Latin-1 gets wrong.
  • BOM handled for you on input and output.
  • Private by design: decoding happens locally in the browser, so you can paste real incident data without a data-handling review.

Frequently Asked Questions

Which encodings are supported?
UTF-8, ANSI (Windows-1252), ISO-8859-1 (Latin-1) and UTF-16 in little-endian or big-endian, with optional byte-order mark. Input can be plain text or hex bytes, and output can be text or hex bytes.
How do I fix garbled (mojibake) log text?
Set the input form to Text, choose the encoding the garbled text currently uses as the source — usually ANSI or Latin-1 for the classic “é” kind of garbling — then set UTF-8 as the target and Convert. The tool rebuilds the original bytes and re-reads them in the correct encoding.
What is the difference between Text and Hex input?
Text treats what you pasted as characters whose raw byte form is described by the source encoding — ideal for repairing display mojibake. Hex treats the input as actual byte values, so you can transcode data exactly, including 0x00 and other non-printable bytes.
How does auto-detection work?
It looks for a byte-order mark first (UTF-8 EF BB BF, UTF-16LE FF FE, UTF-16BE FE FF), then checks whether the bytes are valid UTF-8, and falls back to ANSI/Windows-1252 when they are not.
Is the byte-order mark preserved?
A BOM is stripped automatically when decoding bytes, and the “include BOM” option adds one to hex output for UTF-8 and UTF-16. Toggle it whenever your target tool needs a specific BOM.
Can I see the raw bytes?
Yes. Set the output form to Hex and the tool prints every byte of the converted data as two-digit hex, handy for pasting into scripts, tests or truth-checking against a file on disk.
Is my data uploaded?
No. All encoding and decoding happens entirely in your browser with the built-in TextEncoder/TextDecoder; nothing is sent to a server, stored or logged.