Copying Content Styled with Text-Transform

A ≠ a Using the CSS property text-transform to automatically shift copy to uppercase has been popular for a while now, but a combination of a recent explosion in the use of that style and my slow move to Chrome as my default browser has caused me to regularly paste text into emails, tweets, and blog posts that is not what I expect.

If you’ve had to support a WYSIWYG editor you are probably already familiar with the style-purging technique of copying content from a web page or Microsoft Word, pasting it into a plain text editor (Notepad in my case), and then copying it from there to then paste it into your WYSIWYG editor window. WYSIWYG editors have caught up in the last few years and offered options to paste content as plain text, sans formatting.

The problem is that none of those techniques addresses when the lowercase characters have been replaced with uppercase characters (or vice versa). This isn’t a style you can purge, the characters are truly different.

Testing It

I was curious to see how the browsers have handled text copied from a page where the content was styled to uppercase. I made the following sample block using the text-transform values capitalize, uppercase, lowercase, and full-width:

This content has no text-transform applied to it.

This content has text-transform: capitalize applied to it.

This content has text-transform: uppercase applied to it.

This content has text-transform: lowercase applied to it.

This content has text-transform: full-width applied to it.

I then fired up the following browsers and copied that block of text from each one, pasting into a Notepad (or equivalent) window each time:


All the Webkit browsers (Safari, Mobile Safari, Android Browser, Chrome) behaved the same. They each kept the capitalized text (and the lowercase initial character, where it was styled that way):

This content has no text-transform applied to it.

This Content Has Text-Transform: Capitalize Applied To It.


this content has text-transform: lowercase applied to it.

This content has text-transform: full-width applied to it.

On a side note, screen reader NVDA pronounces the word “it” as “IT” (eye-tee) when it has the text-transform: uppercase style applied. This happens regardless of browser.


I installed some Chrome extensions that promise to remove all formatting, specifically Copy Plain Text 0.1, Copy Without Formatting 0.31, and Plain Text Copy And Paste 1.1.0. None of them revert the text case back to what it is in the source code.

I went to both the CSS 2.1 and CSS3 specifications to see if there is direction to browser makers on how to treat text that has been styled with text-transform, but I see nothing defining how browsers should put that content into the clipboard.


I have an issue with how WebKit handles this. The fact that it breaks from my experience with other browsers, and thus my expectation, is more my issue. I can’t hold WebKit responsible for that. I can, however, hold WebKit responsible for requiring me to either view the source code or open it in another browser to copy the unmodified text.

I feel that changing case is not just technically a matter of changing the specific character entity, but it also changes the meaning of the text when taken out of context. For example, let’s say I write a blog post titled Adrian Likes Bananas, style it with a special typeface and shift it to all caps. This reads differently when someone copies it (without my custom typeface that softens the all-caps effect) and tweets the “shouted” version of the title, ADRIAN LIKES BANANAS. It actually makes the title read as if it’s gone … bananas.

Add to this the unintended acronymization (look, a new word) by screen readers as I show in the it/IT example above, and you run a further risk of creating a confusing block of pasted copy when pulling from Chrome.

I am curious if others feel the same way as I do, or have a different expectation. Bonus if someone can point me to where the W3C specifications define how a user agent should treat this styled content when posted to the clipboard.

There is a bug filed, from July 29, 2010, that is still open as of this writing: Bug 43202 – text-transform shouldn’t apply when copying text

Update: July 8, 2016

Thanks to a kind response to a grumpy tweet, it looks like this issue is getting some attention (it is now on the radar).



Payman, very close. That post talks about text submitted via a form, not copied. However, the link from that post to the W3C language of, "It has no effect on the underlying content," makes me think Webkit has run afoul of the spec. The underlying content has been changed when I copy because it has replaced characters.


I feel the same way. Searched for this hoping for a workaround, but it seems nothing can be done… *sigh. Was really hoping for an extension that would fix this. Too bad :(

Leave a Comment or Response

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>