For example, the string “abcxyz” has a DEL in the middle of it. Copy paste that from this message into npp and you will see “abcxyz”. If you use the left/right arrow keys to step a character forwards or backwards you can see the hitch where it’s stepping over the DEL. I tried npp’s “Show all characters” mode but that does not help.

I can search for them using \x7f

That prompted me to test character values 0x00 to 0x1F. Those all displayed correctly using the ASCII name in white lettering on a black background NUL, SOH, STX, … up to US which is character \x1F. I did not need to use Show All Characters mode other than to see \x09 TAB which displays as —>, \x0A LF, 0x0D CR.

FWIW, I then tested using characters 0x80 to 0xFF in a .txt file (ANSI mode) and see the “nothing displayed” issue for

\x7F - DEL in Windows-1252 and is Unicode Character ‘DELETE’ (U+007F)

\x81 - Undefined in Windows-1252 and is Unicode Character ‘<control>’ (U+0081)

\x8D - Undefined in Windows-1252 and is Unicode Character ‘REVERSE LINE FEED’ (U+008D)

\x8F - Undefined in Windows-1252 and is Unicode Character ‘SINGLE SHIFT THREE’ (U+008F)

\x90 - Undefined in Windows-1252 and is Unicode Character ‘DEVICE CONTROL STRING’ (U+0090)

\x9D - Undefined in Windows-1252 and is Unicode Character ‘OPERATING SYSTEM COMMAND’ (U+009D)

I’m aware that this is partially a font issue. Whatever font npp uses to display text files does not have visible glyphs at those character positions. I suspect, that will be the case for many fonts on many versions of Windows.

FWIW, Windows Notepad also has the same behavior though notepad has visible characters at many positions in the 0x00 to 0x1F range.