Which four string-manipulation types does the TypeScript compiler provide as built-ins, what does each do, and why can you not implement them yourself in the type system?

## The four types TypeScript ships exactly four string-manipulation types, and they operate on string literal types rather than on values: ```ts type A = Uppercase<"hello">; // "HELLO" type B = Lowercase<"HELLO">; // "hello" type C = Capitalize<"hello world">; // "Hello world" type D = Uncapitalize<"HelloWorld">; // "helloWorld" ``` The pair that trips people up is `Capitalize` and `Uncapitalize`: they touch the **first character only**. `Capitalize<"hello world">` is `"Hello world"`, not `"Hello World"` — there is no word-splitting anywhere in the type system. ## How they behave on non-single-literal inputs They distribute over unions, one result per member: ```ts type Keys = Uppercase<"id" | "name">; // "ID" | "NAME" ``` Applied to the primitive, they are the identity: `Uppercase<string>` is `string`, because the compiler cannot know which characters are present, and every uppercase string is still a string. Applied to a pattern type, the fixed segments transform and the hole stays open. None of this is arithmetic on values — the input must be a type, so `Uppercase<typeof someVariable>` works only when that variable has a literal type (typically because it was declared `const` or asserted `as const`). ## Why you cannot write them Type-level string work in TypeScript is built from two primitives: template literal types, which construct and pattern-match strings, and `infer`, which captures a matched piece. You can split a literal into its first character and the rest: ```ts type Head<S extends string> = S extends `${infer H}${string}` ? H : never; type H = Head<"abc">; // "a" ``` What you cannot do is transform that character. There is no type-level table mapping `"a"` to `"A"`, no character-code operation, no comparison operator over characters. The only way to write case conversion in pure TypeScript types would be to hand-author a 26-entry (or, for full Unicode, hopeless) lookup type per direction — which is exactly why the feature is built into the compiler instead. ## The `intrinsic` marker Open `lib.es5.d.ts` and the declarations read: ```ts type Uppercase<S extends string> = intrinsic; type Lowercase<S extends string> = intrinsic; type Capitalize<S extends string> = intrinsic; type Uncapitalize<S extends string> = intrinsic; ``` `intrinsic` is not a type you can use. It is a marker that tells the checker "the implementation of this alias lives in the compiler's own code". Writing `type MyThing<S> = intrinsic;` in application code is rejected with a message stating that the `intrinsic` keyword may only be used to declare compiler-provided intrinsic types. So the set of four is closed: you cannot add a fifth, and any library claiming a `Titlecase` type is implementing it with a hand-written character map or not at all. ## Where they earn their place On their own they are a curiosity. Combined with template literal types they let you derive one naming convention from another: ```ts type Event = "click" | "focus"; type HandlerName = `on${Capitalize<Event>}`; // "onClick" | "onFocus" type Env = Uppercase<`app_${"host" | "port"}`>; // "APP_HOST" | "APP_PORT" ``` That is the shape most real usage takes: a small source vocabulary in one convention, a derived vocabulary in another, kept in sync by the compiler rather than by a comment. ## Compile-time only All four are erased. `Uppercase<"a">` produces no `toUpperCase()` call and no runtime value; if you need the actual uppercased string at runtime you still call the JavaScript method. A frequent confusion is expecting the type to transform data — it only describes what the data must already look like. If a runtime value must match the derived type, the transformation has to exist in the code too, and the type merely checks that it does.