Why does my text file start with ÿþ?

The file is UTF-16, and ÿþ is its byte order mark, FF FE, read as Windows-1252. Every letter after it is followed by a zero byte, which is why the text looks spaced out or full of NULs. Windows PowerShell 5.1 writes UTF-16 when you redirect with >, so use `Out-File -Encoding utf8` instead, or reopen the file as UTF-16 LE.

Why does my page show ÿØÿà and then garbage?

You're looking at a JPEG as text. Every JPEG starts with the bytes FF D8 FF, usually followed by E0, and Windows-1252 draws those as ÿØÿà. Most often the server sent image data with a text Content-Type, or a script echoed the file into an HTML page. Send it with Content-Type: image/jpeg, or point an img tag at it instead.

Is ÿ the same as the Dutch ij?

No. Dutch ij is two letters, and at the start of a word both get capitalized: IJsselmeer, IJmuiden. Handwritten ij can look like ÿ, and some old documents spell it that way, but modern text should use a plain i and j. Unicode also has a single ĳ character for compatibility, which only matches ij after NFKC normalization.

Why does uppercasing ÿ break my Latin-1 export?

ISO-8859-1 has no capital Ÿ, and neither do the DOS code pages, so uppercasing a string turns ÿ into U+0178, which those encodings can't store. In Python, 'ÿ'.upper().encode('latin-1') raises UnicodeEncodeError. Windows-1252 does have the capital, at byte 159, and UTF-8 has everything.

Why does my old DOS file have ÿ between words?

The file used byte 255, the DOS non-breaking space, as a hard space between words, and Windows-1252 reads that byte as ÿ. Outside a few French names, ÿ never occurs as a real letter, so replace every ÿ with a plain space, or with U+00A0 if you want to keep the no-break behavior.

ASCII 255

Lowercase y with umlautNon-breaking space

ASCII 255 is ÿ on Windows and a non-breaking space in old DOS.

ÿ (Small Y with Diaeresis) is byte 255 in Windows-1252, Unicode U+00FF. In words it's limited to a few French names. As the byte FF, though, it's behind a classic C bug. Where plain char is signed, as on x86 compilers, char c = fgetc(f) stores FF as -1, the same value as EOF, so a loop like while ((c = fgetc(f)) != EOF) stops at the first ÿ in a Latin-1 or Windows-1252 file and silently drops the rest. Declare c as int, which is what fgetc returns, and the loop sees 255 and keeps going. Old DOS had ÿ at 152. In UTF-8 it's C3 BF, which misreads as Ã¿. The HTML entity is ÿ.

NBSP (Non-Breaking Space) is byte 255 in code page 437, the original IBM PC character set, and maps to Unicode U+00A0. It prints as a blank, and DOS users turned that into a trick: a file or folder named with it looks nameless or space-filled in a listing but is a perfectly valid name. Such names are hard to type and easy to miss in scripts, because a command line that splits on spaces doesn't treat this character as one. Rename them with a tool that shows code points, or with a wildcard pattern. Windows-1252 has ÿ at 255, so DOS text read that way shows ÿ wherever this space was. Code page 850 kept the non-breaking space here too.

Latin LetterWhitespace

Technical Details

Code Example

</>

#include <stdio.h>

int main(void) {
    /* On Windows (code page 1252) byte 255 is ÿ.
       Modern terminals expect UTF-8, so print the code point, not the byte. */
    printf("\u00FF\n");   /* UTF-8: C3 BF */

    unsigned char b = 255;         /* the raw Windows-1252 byte */
    printf("%d 0x%02X\n", b, b);    /* 255 0xFF */
    return 0;
}

Code Example

</>

#include <stdio.h>

int main(void) {
    /* Byte 255 is non-breaking space only on a console using code page 437
       (chcp 437 on Windows, or DOSBox). On a UTF-8 terminal the
       lone byte 0xFF is invalid and prints as garbage, often �. */
    putchar(255);

    /* char is signed on x86, so a plain char holding 0xFF is -1.
       Use unsigned char when you compare or index by byte value. */
    char c = (char)255;
    unsigned char u = 255;
    printf("\n%d %d\n", c, u);   /* -1 255 */

    /* Portable: print the Unicode character as UTF-8 instead. */
    printf("\u00A0\n");          /* C2 A0 */
    return 0;
}

How to Type It

Windows: Hold Alt and type 0255 on the numeric keypad, with Num Lock on. The leading zero picks the Windows code page. Alt+152, without the zero, types it too. No numeric keypad? In Word, type 00FF and press Alt+X.
Mac: Press Option+U, then y.
Linux: In GNOME, or any desktop running IBus, press Ctrl+Shift+U, type ff, then Space. With a Compose key set up, press Compose, quote, y.
Phone: iPhone: long-press y and pick ÿ. Android (Gboard): tap the character at the top of this page to copy it.

How to Type It

Windows: Hold Alt and type 255 on the numeric keypad, with no leading zero. Windows reads it as a DOS code and inserts a non-breaking space.

The no-break space is also ASCII 160 on Windows, which has the full guide.

Frequently Asked Questions

The file is UTF-16, and ÿþ is its byte order mark, FF FE, read as Windows-1252. Every letter after it is followed by a zero byte, which is why the text looks spaced out or full of NULs. Windows PowerShell 5.1 writes UTF-16 when you redirect with >, so use `Out-File -Encoding utf8` instead, or reopen the file as UTF-16 LE.
You're looking at a JPEG as text. Every JPEG starts with the bytes FF D8 FF, usually followed by E0, and Windows-1252 draws those as ÿØÿà. Most often the server sent image data with a text Content-Type, or a script echoed the file into an HTML page. Send it with Content-Type: image/jpeg, or point an img tag at it instead.
No. Dutch ij is two letters, and at the start of a word both get capitalized: IJsselmeer, IJmuiden. Handwritten ij can look like ÿ, and some old documents spell it that way, but modern text should use a plain i and j. Unicode also has a single ĳ character for compatibility, which only matches ij after NFKC normalization.
ISO-8859-1 has no capital Ÿ, and neither do the DOS code pages, so uppercasing a string turns ÿ into U+0178, which those encodings can't store. In Python, 'ÿ'.upper().encode('latin-1') raises UnicodeEncodeError. Windows-1252 does have the capital, at byte 159, and UTF-8 has everything.
The file used byte 255, the DOS non-breaking space, as a hard space between words, and Windows-1252 reads that byte as ÿ. Outside a few French names, ÿ never occurs as a real letter, so replace every ÿ with a plain space, or with U+00A0 if you want to keep the no-break behavior.

Frequently Asked Questions

The file used byte 255, the DOS non-breaking space, as a hard space between words, and Windows-1252 reads that byte as ÿ. Outside a few French names, ÿ never occurs as a real letter, so replace every ÿ with a plain space, or with U+00A0 if you want to keep the no-break behavior.

ASCII 255

Lowercase y with umlautNon-breaking space

ASCII 255 is ÿ on Windows and a non-breaking space in old DOS.

Latin Letter

Whitespace

#include <stdio.h>

int main(void) {

/* On Windows (code page 1252) byte 255 is ÿ.

Modern terminals expect UTF-8, so print the code point, not the byte. */

printf("\u00FF\n"); /* UTF-8: C3 BF */

unsigned char b = 255; /* the raw Windows-1252 byte */

printf("%d 0x%02X\n", b, b); /* 255 0xFF */

return 0;

}

#include <stdio.h>

int main(void) {

/* Byte 255 is non-breaking space only on a console using code page 437

(chcp 437 on Windows, or DOSBox). On a UTF-8 terminal the

lone byte 0xFF is invalid and prints as garbage, often �. */

putchar(255);

/* char is signed on x86, so a plain char holding 0xFF is -1.

Use unsigned char when you compare or index by byte value. */

char c = (char)255;

unsigned char u = 255;

printf("\n%d %d\n", c, u); /* -1 255 */

/* Portable: print the Unicode character as UTF-8 instead. */

printf("\u00A0\n"); /* C2 A0 */

return 0;

}