About the Byte to String
A byte array printed by a debugger is nearly unreadable, and every language prints it differently. This decoder is deliberately forgiving about shape: square brackets, curly braces, commas, spaces and newlines are all treated as noise, so a Java [80, 97, 121], a Python b'\x50\x61' style listing and a bare column of numbers each parse without editing.
Detection looks at the values themselves. A 0x prefix or a hex only letter means base sixteen, long runs of ones and zeros mean binary, and everything else is decimal. Force the base whenever the array is short enough to be ambiguous. Every value is then checked against the range a byte can hold, and anything over 255 stops the conversion with the number quoted, which is the usual sign that the base guess was wrong or that the array actually holds code points rather than bytes.
UTF-8 decoding is applied by default, so a sequence like 195 169 becomes a single accented character instead of two symbols. Latin-1 keeps the one byte per character rule for older data. When the array really does contain code points above 255, ASCII to Text handles it, and Hex to String is a better fit when the values arrive as a continuous hex dump.
How to use
- Paste the byte array exactly as your debugger or log printed it.
- Leave the base on automatic, or set it if the values are ambiguous.
- Pick Latin-1 when the data comes from a pre Unicode system.
- Copy the decoded string.
Common questions
- Do I need to remove the brackets first?
- No. Brackets, braces and commas are ignored, so you can paste the array exactly as printed.
- Why does a value over 255 fail?
- A byte holds 0 to 255. A larger number means the base was misread or the array holds code points, not bytes.
- Can it read signed bytes from Java?
- Negative values are not bytes in this sense. Convert them by adding 256 to any negative number before pasting.
- Does it handle an array split over many lines?
- Yes. Line breaks count as separators, so a long wrapped array works as it stands.