Convertor PRO — Tips & Tricks

Back to the overview: Convertor PRO · Open the live tool: www.jpkc.com/tools/convertor/

The Manual explains every field, the 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. Tab and button names are given exactly as they appear in the interface.

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, INI, and XML 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.
• Strings survive, numbers and structure not always. Strings like 0755, +49, or yes don't quietly turn into numbers or booleans, and from JSON even 20-digit IDs and 1.0 come out digit for digit (except inside lists that INI writes as a JSON string). But digit-exact only applies to the way out of JSON: when the tool reads YAML, large integers are rounded and 1.0 becomes 1 — without a notice. So JSON → YAML → JSON is not a clean round-trip for such numbers; keep the JSON original. As soon as XML (with its @attr/#text translation) or INI (with its flat structure) is involved, the round-trip result may differ structurally. Plan such conversions as a one-way street, not a there-and-back.

Take the yellow notice box seriously

Where a target format cannot express something, the tool adapts the data — and tells you so below the editors in the box "Not everything fits the target format:", with the path to the spot. Typical cases: null is dropped in TOML, inf/nan become null in JSON, an integer that is too large turns into a string in TOML, a key with a space becomes <a_b> in XML. Read the box before you use the output. An empty box is no guarantee, though: comments and formatting, the dot notation for deep objects in INI, the <root> wrapper in XML, numbers from YAML and TOML sources, the trailing zero of 1.10 from JSON, and TOML dates that turn into strings all go without a notice. The full list is in the manual.

Jump straight to the error line

If the input can't be read, the red error message usually names line and column — and the Go to line … button puts the cursor right there. In a long YAML or JSON file that beats any search. If the source is on Auto-detect and no parser accepts the input, all you get is "The format was not recognized"; in that case set the expected format on the left by hand to see that parser's exact error message.

INI is the narrowest form — go there last

INI has the weakest data model of the five formats: only one section level, no nested lists. Convert something nested to INI and deep objects are flattened with dot notation (db.host = …) without a notice, lists of plain values become key[] = … lines, and lists containing objects or lists end up as a JSON string in the value. When read back, the dot notation stays a flat key. 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.

Trust the format detection — but not blindly

Auto-detect doesn't guess from patterns; it test-parses the input: XML, JSON, TOML, YAML, INI — strict formats first. The badge next to Source shows what was detected. Edge cases still exist, because some texts are valid in several formats: [server] with port = 8080 is valid TOML and valid INI and is detected as TOML. For port that makes no difference, but for values like size = 1e3 or mask = 0x10 it does: TOML reads them as the numbers 1000 and 16, while INI leaves them as the strings "1e3" and "0x10". Rule of thumb: glance at the badge, and set the format by hand when in doubt.

Watch out when switching between files: for a definite extension (.json, .toml, …), Open file sets the source format to that format for good. If you paste something else afterwards, the setting stays — switch back to Auto-detect yourself.

Encoding: Keep ASCII as an "only the exotic" switch

In the Encoding tab, the Keep 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 Keep ASCII, only the non-ASCII Ü becomes a hex NCR — result Über, the ASCII letters ber stay as they are. 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. With Keep Latin-1, umlauts, ß, and é stay as they are as well.

Don't be surprised if individual letters get converted in the Unicode U+hex field despite Keep ASCII: there, Über becomes U+00DC U+0062 U+0065r. A b or e directly after U+00DC would be read back as another hex digit — so the tool writes such characters as a notation to keep the conversion lossless.

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, a \u00E9 — don't laboriously type it into individual fields. Throw it into Mixed input: the field recognizes the various notations in a single pass and gives you the plain text. Two things are worth keeping in mind:

• Backslashes: with the Decode \n, \t, \xHH checkbox off, paths like C:\temp stay intact — but only if no path segment after a backslash starts with 0–9 or a–f: C:\data turns into C:Úta, because \da counts as a CSS escape. For JavaScript or JSON strings with \n and \t, switch it on.
• Hex CP, Dec CP, UTF-8, UTF-16 additionally resolve bare numbers. That's ideal for hex dumps and code-point lists, but only there: words made up solely of the letters A–F (Add, bad, cafe) are hex numbers to Hex CP too and get decoded along with the rest. For running text with escapes sprinkled in, use Convert.

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, nothing stored. 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 — 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 — for encoding operations beyond character conversion: Base64, Punycode, Quoted-Printable, JWT, and Data URIs. Where Convertor PRO stops at character representations, Coder carries on.
• Hash Generator — when you don't need another notation of a text but a checksum or a password hash.