You're here because your file got saved as ASCII and turned a perfectly good unicode string into mojibake, or because you need to put an emoji in a C string literal. Both are Unicode escape territory. Both are annoying.
The format you'll see most is JavaScript's uXXXX escape โ four hex digits for a code point in the Basic Multilingual Plane. A is just "A". The copyright sign is the actual character. For anything past U+FFFF (which is where most emoji and some rare scripts live), the rules diverge by language, and this is where the fun starts.
JavaScript uses surrogate pairs: uD83DuDE00 for the grinning-face emoji. Python uses U0001F600 (capital U, eight hex digits). Java uses the same surrogate pairs as JavaScript. C11 added U0001F600 like Python. Pick the wrong format for your target language and you get a syntax error, or worse โ silent mis-encoding that only shows up when you run the code.
The "preserve ASCII" mode is the practical default for most work. Paste "Hello โ ใใใซใกใฏ ๐" and get back "Hello u2014 u3053u3093u306bu3061u306f uD83D uDE00." All your English and punctuation stays readable, only the non-ASCII parts get escaped. That's 90% of real use cases โ localized strings with plenty of Latin characters mixed in.
Escape-all mode gives you pure ASCII output: every single character becomes a unicode escape. Useful when you need guaranteed transport-safe output. Bad for readability.
Be aware: these escapes are resolved at compile/parse time, not runtime. A is identical to A in the compiled code โ no performance cost, no benefit either. The only reason to escape is compatibility: legacy editors that don't handle UTF-8, source files exchanged between teams with different locale configs, include files in environments where the encoding sanitization breaks multi-byte sequences.
Most modern stacks handle Unicode natively. Files are UTF-8, editors are UTF-8, HTTP headers declare UTF-8. If you're still shipping escaped strings "just to be safe" in a greenfield project, you might be overthinking it. The exceptions: embedded systems with tiny libc, some Windows APIs that want UTF-16-wchar strings, legacy databases with Latin-1 encoding. Everything else โ use the real characters.
The brace notation u{XXXXX} (ES2015+) is only in newer JS engines. If your code targets IE11 or older Android WebViews, stick with the classic uXXXX. Check your browser support matrix before upgrading format.