Edit - Stack Overflow

You are not logged in. Your edit will be placed in a queue until it is peer reviewed.

We welcome edits that make the post easier to understand and more valuable for readers. Because community members review edits, please try to make the post substantially better than how you found it, for example, by fixing grammar or adding additional resources and hyperlinks.

Required fields*

Rev

Required fields*

How do I make the first letter of a string uppercase in JavaScript?

How do I make the first character of a string uppercase if it's a letter, but not change the case of any of the other letters?

For example:

"this is a test" → "This is a test"
"the Eiffel Tower" → "The Eiffel Tower"
"/index.html" → "/index.html"

Answer*

I didn’t see any mention in the existing answers of issues related to <s>astral plane code points or</s> internationalization. “Uppercase” doesn’t mean the same thing in every language using a given script.

_Initially I didn’t see any answers addressing issues related to astral plane code points. There [is one](https://stackoverflow.com/a/45224904/1631952), but it’s a bit buried (like this one will be, I guess!)_ 

Overview of the hidden problem and various approaches to it
---

Most of the proposed functions look like this:

 function capitalizeFirstLetter(str) {
 return str[0].toUpperCase() + str.slice(1);
 }

However, some cased characters fall outside the BMP (basic multilingual plane, code points U+0 to U+FFFF). For example take this Deseret text:

 capitalizeFirstLetter("𐐶𐐲𐑌𐐼𐐲𐑉"); // "𐐶𐐲𐑌𐐼𐐲𐑉"

The first character here fails to capitalize because the array-indexed properties of strings don’t access “characters” or code points*. They access UTF-16 code units. This is true also when slicing — the index values point at code units.

It happens to be that UTF-16 code units are 1:1 with USV (Unicode scalar value) code points within two ranges, U+0 to U+D7FF and U+E000 to U+FFFF inclusive. Most cased characters fall into those two ranges, but not all of them.

From ES2015 on, dealing with this became a bit easier. `String.prototype[@@iterator]` yields strings corresponding to code points\*\*. So for example, we can do this:

 function capitalizeFirstLetter([ first='', ...rest ]) {
 return [ first.toUpperCase(), ...rest ].join('');
 }

 capitalizeFirstLetter("𐐶𐐲𐑌𐐼𐐲𐑉") // "𐐎𐐲𐑌𐐼𐐲𐑉"

For longer strings, this is probably not terribly efficient\*\*\* — we don’t really need to iterate the remainder. We could use `String.prototype.codePointAt` to get at that first (possible) letter, but we’d still need to determine where the slice should begin. One way to avoid iterating the remainder would be to test whether the first codepoint is outside the BMP; if it isn’t, the slice begins at 1, and if it is, the slice begins at 2.

 function capitalizeFirstLetter(str) {
 if (!str) return '';

 const firstCodePoint = str.codePointAt(0);
 const index = firstCodePoint > 0xFFFF ? 2 : 1;

 return String.fromCodePoint(firstCodePoint).toUpperCase() + str.slice(index);
 }

 capitalizeFirstLetter("𐐶𐐲𐑌𐐼𐐲𐑉") // "𐐎𐐲𐑌𐐼𐐲𐑉"

_You could use bitwise math instead of `> 0xFFFF` there, but it’s probably easier to understand this way and either would achieve the same thing._

We can also make this work in ES5 and below by taking that logic a bit further if necessary. There are no intrinsic methods in ES5 for working with codepoints, so we have to manually test whether the first code unit is a surrogate\*\*\*\*:

 function capitalizeFirstLetter(str) {
 if (!str) return '';

 var firstCodeUnit = str[0];

 if (firstCodeUnit < '\uD800' || firstCodeUnit > '\uDFFF') {
 return str[0].toUpperCase() + str.slice(1);
 }

 return str.slice(0, 2).toUpperCase() + str.slice(2);
 }

 capitalizeFirstLetter("𐐶𐐲𐑌𐐼𐐲𐑉") // "𐐎𐐲𐑌𐐼𐐲𐑉"

Deeper into internationalization (_whose_ capitalization?)
---

At the start I also mentioned internationalization considerations. Some of these are very difficult to account for because they require knowledge not only of _what_ language is being used, but also may require specific knowledge of the words in the language. For example, the Irish digraph "mb" capitalizes as "mB" at the start of a word. Another example, the German eszett, never begins a word (afaik), but still helps illustrate the problem. The lowercase eszett (“ß”) capitalizes to “SS,” but “SS” could lowercase to either “ß” or “ss” — you require out-of-band knowledge of the German language to know which is correct!

The most famous example of these kinds of issues, probably, is Turkish. In Turkish Latin, the capital form of i is İ, while the lowercase form of I is ı — they’re two different letters. Fortunately we do have a way to account for this:

 function capitalizeFirstLetter([ first='', ...rest ], locale) {
 return [ first.toLocaleUpperCase(locale), ...rest ].join('');
 }

 capitalizeFirstLetter("italy", "en") // "Italy"
 capitalizeFirstLetter("italya", "tr") // "İtalya"

In a browser, the user’s most-preferred language tag is indicated by `navigator.language`, a list in order of preference is found at `navigator.languages`, and a given DOM element’s language can be obtained (usually) with `Object(element.closest('[lang]')).lang || YOUR_DEFAULT_HERE` in multilanguage documents.

In agents which support Unicode property character classes in RegExp, which were introduced in ES2018, we can clean stuff up further by directly expressing what characters we’re interested in:

 function capitalizeFirstLetter(str, locale=navigator.language) {
 return str.replace(/^\p{CWU}/u, char => char.toLocaleUpperCase(locale));
 }

This could be tweaked a bit to also handle capitalizing multiple words in a string with fairly good accuracy for at least some languages, though outlying cases will be hard to avoid completely if doing so no matter what the primary language is.

The `\p{CWU}` or [Changes_When_Uppercased](https://unicode.org/reports/tr44/#CWU) character property matches all code points which change when uppercased in the generic case where specific locale data is absent. There are other interesting case-related Unicode character properties that you may wish to play around with. It’s a cool zone to explore but we’d go on all day if we enumerated em all here. Here’s something to get your curiosity going if you’re unfamiliar, though: `\p{Lower}` is a larger group than `\p{LowercaseLetter}` (aka `\p{Ll}`) — conveniently illustrated [by the default character set comparison in this tool provided by Unicode](https://util.unicode.org/UnicodeJsps/unicodeset.jsp). _(NB: not everything you can reference there is also available in ES regular expressions, but most of the stuff you’re likely to want is)._

Alternatives to case-mapping in JS (Firefox & CSS love the Dutch!)
---

If digraphs with unique locale/language/orthography capitalization rules happen to have a single-codepoint “composed” representation in Unicode, these might be used to make one’s capitalization expectations explicit even in the absence of locale data. For example, we could prefer the composed i-j digraph, [ĳ](https://en.wikipedia.org/wiki/IJ_(digraph)) / U+133, associated with Dutch, to ensure a case-mapping to uppercase Ĳ / U+132:

 capitalizeFirstLetter('ĳsselmeer'); // "Ĳsselmeer"

On the other hand, precomposed digraphs and similar are sometimes deprecated (like that one, it seems!) and may be undesirable in interchanged text regardless due to the potential copypaste nuisance if that’s not the normal way folks type the sequence in practice. Unfortunately, in the absence of the precomposition “hint,” an explicit locale won’t help here (at least as far as I know). If we spell `ijsselmeer` with an ordinary `i` + `j`, `capitalizeFirstLetter` will produce the wrong result even if we explicitly indicate `nl` as the locale:

 capitalizeFirstLetter('ijsselmeer', 'nl'); // "Ijsselmeer" :(

_(I’m not entirely sure whether there are some such cases where the behavior comes down to ICU data availability — perhaps someone else could say.)_

If the point of the transformation is to display textual content in a web browser, though, you have an entirely different option available that will likely be your best bet: leveraging features of the web platform’s other core languages, HTML and CSS. Armed with HTML’s `lang=...` and CSS’s `text-transform:...`, you’ve got a (pseudo-)declarative solution that leaves extra room for the user agent to be _“smart.”_ A JS API needs to have predictable outcomes across all browsers (generally) and isn’t free to experiment with heuristics. The user-agent itself is obligated only to its user, though, and heuristic solutions are fair game when the output is for a human being. If we tell it “this text is Dutch, but please display it capitalized,” the particular outcome might now vary between browsers, but it’s likely going to be the best each of them could do. Let’s see:





 <!DOCTYPE html>
 <dl>
 <dt>Untransformed
 <dd>ijsselmeer
 <dt>Capitalized with CSS and <code>lang=en</code>
 <dd lang="en" style="text-transform: capitalize">ijsselmeer
 <dt>Capitalized with CSS and <code>lang=nl</code>
 <dd lang="nl" style="text-transform: capitalize">ijsselmeer



In Chromium at the time of writing, both the English and Dutch lines come out as `Ijsselmeer` — so it does no better than JS. But try it in current Firefox! The element that we told the browser contains Dutch will be correctly rendered as `IJsselmeer` there.

_This solution is purpose-specific (it’s not gonna help you in Node, anyway) but it was silly of me not to draw attention to it previously given some folks might not realize they’re googling the wrong question. Thanks @paul23 for clarifying more about the nature of the IJ digraph in practice and prompting further investigation!_

---

As of January 2021, all major engines have implemented the Unicode property character class feature, but depending on your target support range you may not be able to use it safely yet. The last browser to introduce support was Firefox (78; June 30, 2020). You can check for support of this feature with the [Kangax compat table](http://kangax.github.io/compat-table/es2016plus/#test-RegExp_Unicode_Property_Escapes). Babel can be used to compile RegExp literals with property references to equivalent patterns without them, but be aware that the resulting code can sometimes be enormous. You probably would not want to do this unless you’re certain the tradeoff is justified for your use case.

---

In all likelihood, people asking this question will not be concerned with Deseret capitalization or internationalization. But it’s good to be aware of these issues because there’s a good chance you’ll encounter them eventually even if they aren’t concerns presently. They’re not “edge” cases, or rather, they’re not _by-definition_ edge cases — there’s a whole country where most people speak Turkish, anyway, and conflating code units with codepoints is a fairly common source of bugs (especially with regard to emoji). Both strings and language are pretty complicated!

---

_\* The code units of UTF-16 / UCS2 are also Unicode code points in the sense that e.g. U+D800 is technically a code point, but that’s not what it “means” here ... sort of ... though it gets pretty fuzzy. What the surrogates definitely are not, though, is USVs (Unicode scalar values)._

_\*\* Though if a surrogate code unit is “orphaned” — i.e., not part of a logical pair — you could still get surrogates here, too._

_\*\*\* maybe. I haven’t tested it. Unless you have determined capitalization is a meaningful bottleneck, I probably wouldn’t sweat it — choose whatever you believe is most clear and readable._

_\*\*\*\* such a function might wish to test both the first and second code units instead of just the first, since it’s possible that the first unit is an orphaned surrogate. For example the input "\uD800x" would capitalize the X as-is, which may or may not be expected._

Draft saved

Draft discarded

Edit Summary*

Cancel

I had been wondering for a while why toUpperCase didn't really do much for some languages... but didn't quite care enough to find out. Glad I finally did, this was a very interesting read!

Stephan Bijzitter
– Stephan Bijzitter

2021年07月19日 22:09:48 +00:00
Commented Jul 19, 2021 at 22:09
This doesn't seem to work with digraphs such as "IJ" in dutch. Using the latest version the example here is incorrectly capitalized to "Ijsselmeer" (The regex version). The code I used was: capitalizeFirstLetter('ijssel', 'nl-NL') - That's a correct localization string right?

paul23
– paul23

2021年08月24日 11:38:41 +00:00
Commented Aug 24, 2021 at 11:38
4

In netherlands dutch IJ is considered 2 letters, which are just capitalized at the same time (in contrary to the belgian version).

paul23
– paul23

2022年06月23日 16:52:50 +00:00
Commented Jun 23, 2022 at 16:52
3

Great answer! Quite embarrassing how many broken answers exist here. I would recommend adding a small "tl;dr" section at the very top.

Lukas Kalbertodt
– Lukas Kalbertodt

2023年09月28日 07:55:30 +00:00
Commented Sep 28, 2023 at 7:55
2

@GéryOgam It may be helpful to know the formal term for what you’re trying to do with the second regular expression in the answer you linked: "segmentation". Segmentation is complex and, in some cases, its behavior varies with language as well. It’s defined by UAC #29. Fortunately, ECMAScript (via ECMA-402, the Intl API) provides an API for this, %Intl.Segmenter%. You’d use granularity: "word".

Semicolon
– Semicolon

2024年07月23日 19:19:11 +00:00
Commented Jul 23, 2024 at 19:19

| Show 6 more comments

How to Edit

Correct minor typos or mistakes
Clarify meaning without changing it
Add related resources or links
Always respect the author’s intent
Don’t use edits to reply to the author

How to Format

create code fences with backticks ` or tildes ~
```
like so
```
add language identifier to highlight code
```python
def function(foo):
print(foo)
```
put returns between paragraphs
for linebreak add 2 spaces at end
_italic_ or **bold**
indent code by 4 spaces
backtick escapes `like _so_`
quote by placing > at start of line
to make links (use https whenever possible)

<https://example.com>

[example](https://example.com)

<a href="https://example.com">example</a>

formatting help »
answering help »

How to Tag

A tag is a keyword or label that categorizes your question with other, similar questions. Choose one or more (up to 5) tags that will help answerers to find and interpret your question.

complete the sentence: my question is about...
use tags that describe things or concepts that are essential, not incidental to your question
favor using existing popular tags
read the descriptions that appear below the tag

If your question is primarily about a topic for which you can't find a tag:

combine multiple words into single-words with hyphens (e.g. python-3.x), up to a maximum of 35 characters
creating new tags is a privilege; if you can't yet create a tag you need, then post this question without it, then ask the community to create it for you

popular tags »

lang-js

CollectivesTM on Stack Overflow

How do I make the first letter of a string uppercase in JavaScript?

Answer*