Two UTF-8 files can display exactly the same text while differing at the byte level. A UTF-8 byte order mark is the three-byte sequence EF BB BF at the start of a file. To distinguish BOM and no-BOM files reliably, compare the leading bytes, the editor’s encoding indicator, and the format after saving a copy.
Understand what the UTF-8 BOM identifies
In a BOM-aware application, the three leading bytes are normally consumed as an encoding marker rather than displayed as manuscript text. That is why a BOM file and a no-BOM file containing the same Japanese sentence can look identical in the editing pane.
The marker is not proof that the text is correct, and it does not guarantee compatibility with every receiving system. It is also not universally required for UTF-8. The relevant question is whether the next tool, collaborator, or publishing pipeline expects it.
Do not use visible appearance as the only test. An application may hide the marker correctly, show an unexpected character when it does not recognize it, or silently rewrite the format during saving.
Prepare a controlled two-file specimen
Create sample-no-bom.txt and sample-bom.txt. Put the same three lines in both: one Japanese sentence, one ASCII sentence, and one line containing an emoji. Keep line endings and text content identical so that the leading marker is the intended variable.
Use a trusted byte-inspection method to examine the start of each file. Record that the BOM specimen begins with EF BB BF and that the no-BOM specimen begins directly with the first encoded text character. Associate the observation with the exact filename; similar names are an easy source of false conclusions.
You do not need to interpret the entire file as hexadecimal for this test. The leading bytes answer the BOM question, while the editor and a text comparison answer the content question.
Compare the editor’s detection with the bytes
Open both files without saving them. Record the encoding label, BOM status if shown, and visible content. A passing observation has identical text with different BOM status. If the editor does not expose BOM status directly, inspect the encoding choice offered for saving and retain the external byte observation.
Prevent automatic saving from changing the specimens before the observation is complete. Use copies or disable the relevant save behavior for the test. Once the original bytes have changed, the test no longer describes the files you created.
Detection and decoding are related but different. An editor may identify a marker and then decode the remaining bytes as UTF-8. The fact that the text displays does not by itself prove how the editor determined the encoding.
Test conversion only on copies
Make one copy of each specimen. Save the BOM copy as UTF-8 without BOM and save the no-BOM copy as UTF-8 with BOM. Keep the originals untouched. Reinspect the first three bytes, reopen the copies, and compare all three content lines.
The expected change is the presence or absence of the marker, not a change to the Japanese, ASCII, or emoji text. If line endings or text content also change, record those differences separately rather than attributing everything to BOM conversion.
A second useful test is preservation. Open a file, make a harmless text edit in a copy, and save it while intentionally keeping the existing UTF-8 variant. Confirm that the selected format is still present afterward.
Decide from the receiving requirement
Check the specification of the program, typesetting process, upload system, or collaborator receiving the file. If it explicitly requires one variant, produce that variant and verify it. If there is no external rule, follow the existing project convention and avoid introducing a mixture without a reason.
Mixed BOM status can create noisy version-control changes or inconsistent processing even when manuscripts look alike. A project record should include the filename, expected encoding, BOM status, inspection result, and receiving requirement.
The documented Rune Studio scope
Current documentation for the Mac version of Rune Studio describes checking a file for a byte order mark before other encoding detection and supporting both UTF-8 without BOM and UTF-8 with BOM. The documented feature set also includes an encoding indication and encoding choice when saving.
These are documented capabilities. They do not prove that the two-file specimen above has been completed, that a BOM makes content valid, or that either UTF-8 variant is accepted by every publishing service. Verify the requirement of the actual destination.
Keep BOM diagnosis separate from damaged text
If text is already garbled, adding or removing a BOM is not a general repair method. Preserve the original bytes, identify the actual source encoding, and decode from that evidence. Repeatedly opening and saving a misdecoded file can destroy information that would otherwise help recovery.
Similarly, an unexpected invisible character at the start of processed output may result from a tool treating BOM bytes as content. Record the bytes and the processing tool before changing the manuscript.
Use two independent observations
The reliable answer comes from two sources: the file begins with or without EF BB BF, and the editor reports or preserves the corresponding format. Visible text is a necessary content check but not a sufficient format check.
To review the currently documented UTF-8 detection and saving scope, see the Rune Studio product page.