UTF-8 is the universal encoding of the modern web. RFC 8259 defines JSON as UTF-8, and every modern JSON parser produces UTF-8 strings on parse. The natural CSV output to match is UTF-8 because any other encoding would require lossy or escape-heavy transcoding of values. FixTools writes UTF-8 directly, which means every character that can be represented in your source JSON is preserved exactly in the CSV.
The BOM (byte-order mark) is a three-byte signature (EF BB BF) at the start of a UTF-8 file that signals the encoding to readers. Excel on Windows uses the BOM to detect UTF-8 reliably; without it, Excel falls back to the system code page and mangles accented characters. macOS Excel, Google Sheets, Apple Numbers, and most text editors handle UTF-8 with or without BOM. The default in FixTools is BOM-on, which is the safe choice for Windows-Excel-bound files. Switch to BOM-off for Unix pipelines where the BOM is sometimes treated as part of the first field.
Emoji and other supplementary-plane Unicode characters (those above U+FFFF, encoded as surrogate pairs in UTF-16) work correctly because UTF-8 represents them as four-byte sequences without any special escaping. A row containing a customer name with an emoji icon (some forms allow them now) preserves the emoji exactly in the CSV.
Common encoding traps in non-UTF-8 contexts include Windows-1252 (the default code page for older Windows systems), ISO-8859-1 (the historical Latin-1 encoding), and Shift_JIS (the Japanese Windows code page). Files written in those encodings render correctly only on systems with matching locale settings, which is why UTF-8 is genuinely better as a portable encoding. If a downstream tool absolutely requires a non-UTF-8 encoding, transcode the CSV after download using iconv or a similar tool.