# Convertor PRO — Tips & Tricks

> Tricks for Convertor PRO: low-loss round-trips, format detection, the ASCII/Latin1 options, and combining it with other JPKCom tools.

Source: https://www.jpkc.com/db/en/tools/convertor/tips/

Back to the overview: [Convertor PRO](https://www.jpkc.com/db/en/tools/convertor/) · Open the live tool: [www.jpkc.com/tools/convertor/](https://www.jpkc.com/tools/convertor/)

The [Manual](https://www.jpkc.com/db/en/tools/convertor/manual/) explains every field, the [Examples](https://www.jpkc.com/db/en/tools/convertor/examples/) show the workflows. This page is about what both assume but rarely state: where the real pitfalls are, when a conversion is lossy, and how to combine Convertor PRO with other tools. The interface is in English, so the actual tab and button names are given as they appear.

## Data formats: what a conversion loses

The most important mental step: every format conversion runs through a **shared data intermediate stage** (a JavaScript object). Whatever that object cannot represent is lost — in either direction.

- **Comments never survive.** YAML, TOML, and INI comments are gone after conversion. If comments matter to you, convert early and comment afterwards in the target format — not the other way around.
- **Order and formatting are not guaranteed.** You get a canonical, cleanly indented output, not your original layout. Bad for a diff against the source; ideal for tidying up.
- **Round-trips are rarely lossless.** JSON → YAML → JSON usually comes back clean because both share the same data model. But as soon as XML (with its `@attr`/`#text` translation) or INI (with its flat structure) is involved, the round-trip result differs structurally. Plan conversions as a one-way street, not a there-and-back.

## INI is the narrowest form — go there last

INI has the weakest data model of the five formats: only one section level. Convert something nested to INI and deep objects are flattened with **dot notation** (`a.b.c`) and arrays become comma-separated values — and an **array at the root level** is rejected outright. Practical rule: **INI only as a target when the data is naturally flat.** For anything richly structured, JSON, YAML, or TOML are the more honest targets. Details in the [Limits in the manual](https://www.jpkc.com/db/en/tools/convertor/manual/#limits-and-edge-cases).

## Trust the format detection — but not blindly

**Paste** and **Open file** guess the source format: by the leading character, by `[section]` headers, by `key:` or `key =` patterns. That saves clicks. But INI and TOML look alike, and the heuristic can be wrong. Rule of thumb: after pasting, glance at the **Source** selector to confirm it shows the format you expect — and correct it by hand if needed before clicking **Convert**. The file extension when opening is more reliable than content detection.

## Encoding: the ASCII checkbox as an "only the exotic" switch

In the **Encoding** tab, the **ASCII** checkbox is the most useful, most overlooked switch. It sits on the *Hexadecimal NCRs*, *Decimal NCRs*, *Unicode U+hex*, and *0x notation* fields (not on the HTML/XML field) and is on by default there. With it, ordinary ASCII characters stay readable and only the "special" characters are converted. Example, the *Hexadecimal NCRs* field, input `Über`: with **Restrict to ASCII** on, only the non-ASCII `Ü` becomes a hex NCR — result `Über`, the ASCII letters `ber` stay as is. Turn the checkbox off and the ASCII characters become NCRs too (`Über`) — a wall of entities you almost never want. If you really need *every* character escaped (e.g. for a strict ASCII transport format), that is exactly the right mode.

## Mixed input is the universal decoder

When you have text from an unknown source with several escape kinds jumbled together — a few `&#x…;`, a `%C3%BC`, an `é` — don't laboriously type it into individual fields. Throw it into **Mixed input** and click **Convert**: the field recognizes the various notations together and gives you the plain text. The **Hex CP** / **Dec CP** / **UTF-8** / **UTF-16** modes additionally hand you the desired code-point or byte view.

## Understand surrogate pairs and emojis correctly

For characters beyond the Basic Multilingual Plane (emojis, many symbols, rare scripts), look at **UTF-16 code units**: there you see the **surrogate pair** with which such characters are represented internally in JavaScript and UTF-16. When a string has "the wrong length" in JS or an emoji breaks when truncated, it is almost always a surrogate problem — Convertor PRO makes it visible.

## Nothing leaves your machine

Convertor PRO is **purely client-side** — no upload, no server round-trip. That's not just fast; it's also why you can convert **configurations with secrets, tokens, or internal hostnames** without worry: the data stays in the browser tab. (Even so: treat outputs you copy or download like the sensitive original.)

## Combining with other JPKCom tools

Convertor PRO settles encoding and format — for what comes before or after, its neighbors in the code-and-text family help:

- **[JSON Editor](https://www.jpkc.com/db/en/tools/json/)** — when you want to work more deeply with the JSON structure after converting: validate, search, edit precisely. Convertor PRO gets you into JSON; the JSON Editor works within it.
- **[Coder](https://www.jpkc.com/db/en/tools/coder/)** — for encoding operations beyond character conversion: Base64, full URL encoding, hashing. Where Convertor PRO stops at character representations, Coder carries on.