Can the UTF-8 Converter detect my file's encoding automatically?

No. Encoding detection is probabilistic and this tool requires an explicit source encoding so the conversion remains auditable and reversible.

Why did the byte count change after converting to UTF-8?

Different encodings use a different number of bytes per character, so a correct UTF-8 conversion often changes the file size in either direction.

Does the output include a UTF-8 BOM?

No. A recognized source BOM is consumed during decoding and the downloaded UTF-8 bytes are emitted without adding one.

Why does my file still show mojibake after switching IntelliJ to UTF-8?

The IDE settings only tell the decoder which label to use; the bytes on disk must also be valid for that label, otherwise IntelliJ substitutes replacement characters or flags the file with an encoding warning.

What is the maximum file size the converter accepts?

Files are limited to 10 MB because the in-memory browser buffer is checked before reading; larger files should be processed with a streaming conversion utility.

Change UTF-8 in IntelliJ IDEA and Verify Source Files

To change a project's encoding to UTF-8 in IntelliJ IDEA, open File then Settings then Editor then File Encodings, set the Global encoding, Project encoding and Default encoding for properties files to UTF-8, then run the UTF-8 Converter on each existing source file to confirm the bytes on disk decode as valid UTF-8 - IntelliJ controls how files are opened, saved and compiled, but it cannot retroactively repair bytes that were produced by an older Windows tool, a misconfigured database export or a legacy editor that wrote Windows-1252 or UTF-16. IntelliJ's encoding settings live in three nested locations, and because they form a presentation layer over the byte stream on disk rather than a transcoder, simply switching the dial to UTF-8 is necessary but not sufficient. The IDE will silently substitute replacement characters, refuse to compile, or push a broken state deeper into version control when an existing file is not actually UTF-8 at the byte level, which is the most common reason developers searching for how to change UTF-8 in IntelliJ end up with files that still look wrong after a restart and a clean build.

IntelliJ encoding settings vs the bytes on disk

Encoding in IntelliJ is read twice for every file: once when the editor displays it and again whenever it is compiled, copied or saved. The Global Encoding affects every new project on the machine, the Project Encoding overrides the global for the current tree, and a per-file encoding override at the bottom of the File Encodings dialog forces one specific label for an individual source file. None of these settings convert bytes; they only tell the standard WHATWG decoder which label to pass to the TextDecoder that IntelliJ uses internally. If the label does not match the bytes that were actually written, IntelliJ will either show replacement diamonds, fail a build step, or mark the file with a warning at the bottom-right corner of the editor. That is why a verification step using a standards-based converter is part of the workflow and not optional when troubleshooting mojibake or build errors that survive a settings change.

The File then Settings path described here matches IntelliJ IDEA 2023 and later; the same dialog is reached on macOS through IntelliJ IDEA then Preferences. Older versions such as 14.x used identical labels with slightly different navigation, and versions before that expose a legacy Other Settings then Default Settings entry that lets a system administrator pre-bake UTF-8 for every new workspace opened on the machine.

Setting UTF-8 throughout IntelliJ IDEA

This walkthrough covers the most common interpretation of the query how to change UTF-8 in IntelliJ, which is to make every project, every file and every properties resource default to UTF-8 without special-casing individual sources.

Open File then Settings on Windows or Linux, or IntelliJ IDEA then Preferences on macOS; the resulting dialog is labelled Settings on every platform.
In the left tree, expand Editor then File Encodings.
Change Global Encoding to UTF-8.
Change Project Encoding to UTF-8.
Change Default encoding for properties files to UTF-8; this affects .properties localization files specifically and IntelliJ warns whenever this differs from UTF-8.
Leave Transparent native-to-ascii conversion unchecked unless the project is known to depend on it; modern code bases should default it off.
Click Apply and then OK; reopen any project that was already open so IntelliJ re-reads the encoding map.
If the bottom-right corner of any open file still shows the encoding as System default or UTF-8 with BOM, switch the file manually or convert it as described in the next section.
For a team-friendly version of the same setting, edit .idea/encodings.xml in the project root and ensure every CHARSET attribute is UTF-8; commit the file so every contributor picks up the same defaults.

The encoding status bar at the bottom right of every editor window is the visible confirmation that the change took effect for the file under focus, and it doubles as the only UI element that proves the IDE is no longer treating the source as System default.

Converting a mislabeled source file to verified UTF-8

When a file pre-dates the IDE settings change, was checked out from an external legacy repository, or was produced by a Windows tool that defaulted to Windows-1252, the IDE cannot repair it by itself and you need an external auditor. The UTF-8 Converter applies the WHATWG decoder with fatal error handling for the four encodings that IntelliJ projects encounter in practice, then re-encodes the result as a downloadable BOM-free file without uploading the source bytes.

Identify the source encoding from the producing application or reliable metadata - do not rely on the file's apparent appearance, because byte sequences can be valid under more than one legacy encoding while representing different characters.
Open the converter and choose the file from disk; files up to 10 MB are read directly into an in-memory buffer.
Confirm the selected source encoding in the selector - UTF-8, UTF-16LE, UTF-16BE or Windows-1252.
Click Convert; the preview area decodes the bytes, displays the rendered characters and reports both source and output byte counts.
If the source is decoded under fatal validation, invalid continuation bytes, truncated sequences, forbidden encodings, unpaired surrogates and other malformations cause an explicit failure rather than replacement characters.
Inspect the preview for representative names, punctuation, currency symbols and non-ASCII lines; an obviously wrong selection is usually visible here before download.
Download the file; the resulting filename gains a -utf8 suffix and the bytes are emitted without a BOM even when the source contained one.
Place the converted file into the IntelliJ project tree, rebuild and verify before deleting the original; the converter does not modify line endings beyond what follows from decoding and UTF-8 encoding.

Different byte counts between source and output are expected because UTF-8 uses a different number of bytes per character than Windows-1252 or UTF-16, and a matching count would actually be suspicious for a legacy source. Files larger than 10 MB should be processed with a streaming conversion utility because the in-memory browser buffer is the operational limit of this tool.

Pitfalls when changing UTF-8 in IntelliJ

Even with the right settings, four recurring issues surface repeatedly when developers try to change UTF-8 in IntelliJ and find that strings still display as mojibake, that compilation fails, or that localization files are flagged with a wrong-encoding warning.

UTF-8 BOMs in properties and Java sources

IntelliJ recognizes a UTF-8 byte-order mark when present, but a BOM in a .properties file or at the start of a Java source causes tooling and shell scripts elsewhere to misread the first line. The converter UTF-8 mode consumes the BOM through the standards-based decoder and the encoder emits the downloaded file without adding one, which is exactly what most build pipelines expect.

Windows-1252 labeled as ISO-8859-1

Windows-1252 is the common Western legacy code page often mislabeled as ISO-8859-1, and bytes 0x80 through 0x9F include printable punctuation and symbols such as the euro sign and curly quotation marks rather than control characters. A Windows-1252 euro byte 0x80 becomes the three UTF-8 bytes E2 82 AC after conversion, so a file that looked four bytes long in the legacy encoding will grow once exported as UTF-8.

UTF-16 byte order confusion

UTF-16LE and UTF-16BE differ only in byte order; the letters in a file become nonsense if endian order is reversed, even though pairs of bytes remain readable. The converter treats a matching BOM as authoritative and pairs UTF-16 surrogate halves before UTF-8 output, so supplementary characters such as emoji are preserved as one Unicode scalar value rather than as two replacement diamonds.

Mixed encodings inside a single file

If a file contains both Windows-1252 bytes and UTF-8 bytes because two editors saved different sections, a single decoder cannot repair it reliably. The converter will either succeed under the chosen label and corrupt the other section, or fail outright under fatal validation; in either case the file needs to be split before any further encoding work can proceed.

IntelliJ file encodings reference

Setting	Scope	Effect on IntelliJ
Global Encoding	Whole IDE, all new projects	Default for every new project created on this machine
Project Encoding	Current project	Overrides the Global value for the active project tree
Default encoding for properties files	.properties resources only	Prevents non-Latin-1 read errors and BOM warnings
Transparent native-to-ascii conversion	Java sources with embedded Unicode	Escapes non-ASCII bytes in source; leave off unless required
Per-file encoding override	Single file	Forces a chosen label regardless of inheritance

The conversion produced by the tool is auditable because the encoder is fixed, the source label is explicit and the file never leaves the browser, which suits compliance-sensitive workflows where IntelliJ silent label changes are not acceptable.

UTF-8 Converter source encoding behavior

Selected source encoding	Decoder behavior	Downloaded UTF-8 output
UTF-8 (no BOM)	Validates with fatal error handling	BOM-free UTF-8 bytes
UTF-8 with BOM	Consumes the leading BOM	BOM-free UTF-8 bytes
UTF-16LE	Decodes little-endian, combines surrogate pairs	BOM-free UTF-8 bytes
UTF-16BE	Decodes big-endian, combines surrogate pairs	BOM-free UTF-8 bytes
Windows-1252	Maps 0x80 to 0x9F printable symbols	BOM-free UTF-8 bytes

Both tables describe values defined by the IntelliJ settings dialog and by the converter specification rather than computed results, so they remain valid for readers comparing their own projects against the documented behavior. The decoder labels follow the WHATWG Encoding Standard, which keeps IntelliJ and the converter in step with every standards-compliant editor on the workstation.