A useful inspection answers a small question: did the export include a byte-order mark, a null byte, or a different line ending? Changing a <meta charset> declaration cannot tell you which bytes were written to disk.
Read one row without editing it
UltraEdit's left column identifies the byte offset at the start of a row. The middle column gives each byte as two hexadecimal digits. The right column shows printable ASCII characters and uses a dot for non-printable bytes. A dot is a display placeholder, not proof that the file contains a literal period.
For an original practice export, these possible beginnings mean different things:
EF BB BF 3C 21 64 6F 63
< ! d o c
3C 21 64 6F 63
< ! d o c
The first sequence places the UTF-8 byte-order mark before <!doc; the second does not. This is an illustrative byte sequence, not an UltraEdit screenshot or a captured export. A UTF-8 BOM is not automatically corruption. Decide whether the receiving tool permits it before changing it.
Meta charset and mojibake explains browser decoding and declarations. Hex inspection answers the earlier disk question: which bytes are actually present?
Search for the sequence you are investigating
While hex mode is active, open Find with Ctrl+F and use its hex search option for a byte pattern. The documented hex search accepts values such as 0D 0A; inspect the matching offset and neighboring bytes. Hex Find
0D 0A carriage return followed by line feed
0A line feed
00 null byte
Finding 0A alone does not show that a file uses only LF line endings: it also occurs as the second byte of 0D 0A. Look at the byte immediately before each relevant match. Likewise, a null byte may be part of UTF-16 text; do not strip every 00 simply because an ASCII view makes it look odd.
For an HTML export containing a suspect separator, record the offset, the exact surrounding bytes, and the visible text on each side. That gives the export owner enough information to reproduce the problem without repeatedly resaving the only original.
Distinguish overwriting from insertion
Typing in UltraEdit hex mode overwrites existing bytes. Inserting or deleting bytes uses the separate Hex Insert/Delete command. Editing the ASCII side also changes the byte values; it is not a harmless annotation area. Hex editing behavior
If you intend to remove a three-byte BOM from a disposable test copy, overwriting it with spaces does not remove three bytes. It replaces them with three different bytes. Use the operation that matches the experiment, then compare the result with the untouched original.
Most HTML corrections belong in the text source or the exporting program. Byte editing is useful for confirming a diagnosis, but it can also break a multibyte character halfway through its encoded representation. TextEncoder examples show why one visible character can occupy several bytes.
Keep null-containing files intact while inspecting
UltraEdit has settings for opening null-containing files in hex mode and for preventing null-to-space conversion when a file is edited as text. Its documentation treats detected UTF-16 separately. Check those settings before making text-mode changes to a suspect binary or mixed-content export. Hex mode settings
When the inspection is complete, close the untouched original without saving. Keep any deliberate byte experiment under a different filename. Reopen that test copy in the receiving program and confirm the specific symptom changed; a cleaner-looking hex row alone does not prove that the HTML now renders correctly.