It’s all too common to see the incorrect HTML used for quotes in markup. In this article, let’s dig into all this, looking at different situations and different HTML tags to handle those situations.
There are three major HTML elements involved in quotations:
<blockquote>
<q>
<cite>
Let’s take a look.
Blockquotes
Blockquote tags are used for distinguishing quoted text from the rest of the content. My tenth grade English teacher drilled it into my head that any quote of four lines or longer should be set apart this way. The HTML spec has no such requirement, but as long as the text is a quote and you want it to be set apart from the surrounding text and tags, a blockquote is the semantic choice.
By default, browsers indent blockquotes by adding margin on each side.
See the Pen
The Blockquote Tag by Undead Institute (@undeadinstitute)
on CodePen.
As a flow element (i.e. “block level” element), blockquote can contain other elements inside it. For example, we can drop paragraphs in there with no problem:
<blockquote>
<p></p>
<p></p>
</blockquote>
But it could be other elements, too, like a heading or an unordered list:
<blockquote>
<h2></h2>
<ul>
<li></li>
<li></li>
</ul>
</blockquote>
It’s important to note that blockquotes should only be used for quotations rather than as a decorative element in a design. This also aids accessibility as screen reader users can jump between blockquotes. Thus a blockquote element used solely for aesthetics could really confuse those users. If you need something more decorative that falls outside the bounds of extended quotations, then perhaps a div with a class is the way to go.
blockquote,
.callout-block {
/* These could share styling */
}
Quoting with Q
Q tags (<q>
) are for inline quotes, or what my tenth grade teacher would say are those under four lines. Many modern browsers will automatically add quotation marks to the quote as pseudo elements but you may need a backup solution for older browsers.
See the Pen
The Q Tag by CSS-Tricks (@css-tricks)
on CodePen.
Typical quotation marks are just as valid for inline quotes as the <q>
element. The benefits of using <q>
, however, are that it includes a cite attribute, automatic handling of quotation marks, and automatic handling of quote levels. <q>
elements should not used for sarcasm (e.g. “you would use a <q>
tag for sarcasm, wouldn’t you?”), or signifying a word with air quotes (e.g. “awesome” is an “accurate” description of the author). But if you can figure out how to mark up air quotes, please let me know. Because that would be “awesome.”
The citation attribute
Both <q>
and blockquotes can use a citation (cite
) attribute. This attribute holds a URL that provides context and/or a reference for the quoted material. The spec makes a point of saying that the URL can be surrounded by spaces. (I’m not sure why that’s pointed out, but if you want to anger the semantic code deities, you’ll have to do more than throw spaces around.)
<p>The officer left a note saying <q cite="https://johnrhea.com/summons">You have been summoned to appear on the 4th day of January on charges of attempted reader bribery.</q></p>
That cite
attribute isn’t visible to the user by default. You could add it in with a sprinkle of CSS magic like the following demo. You could even fiddle with it further to make the citation appear on hover.
See the Pen
Attributable citations by CSS-Tricks (@css-tricks)
on CodePen.
Neither of those options are particularly great. If you need to cite a source such that users can see it and go to it, you should do it in HTML and probably with the <cite>
element, which we’ll cover next.
The citation element
The <cite>
tag should be used for referencing creative work rather than the person who said or wrote the quote. In other words, it’s not for quotes. Here are the examples from the spec:
<p>My favorite book is <cite>The Reality Dysfunction</cite> by
Peter F. Hamilton. My favorite comic is <cite>Pearls Before
Swine</cite> by Stephan Pastis. My favorite track is <cite>Jive
Samba</cite> by the Cannonball Adderley Sextet.</p>
Here’s another example:
See the Pen
Cite This! by CSS-Tricks (@css-tricks)
on CodePen.
If the author of this article told you he’d give you a cupcake, and you <cite>
him by name, that would be semantically incorrect. Thus no cupcakes would change hands. If you cited the article in which he offered you a cupcake, that would be semantically correct, but since the author wouldn’t do that, you still wouldn’t get a cupcake. Sorry.
By default, browsers italicize cite tags and there’s no requirement that a <q>
or <blockquote>
be present to use the cite element. If you want to cite a book or other creative work, then slap it in the cite element. The semantic deities will smile on you for not using either <i>
or <em>
elements.
But where to put the cite element? Inside? Outside? The upside down? If we put it inside the <blockquote>
or the <q>
, we’re making it part of the quote. That’s forbidden by the spec for just that reason.
<!-- This is apparently wrong -->
<blockquote>
Quote about cupcake distribution from an article
<cite>The Article</cite>
</blockquote>
Putting it outside just feels wrong and also requires you to have an enclosing element like a <div>
if you wanted to style them together.
<div class="need-to-style-together">
<blockquote>
Quote about cupcake distribution from an article
</blockquote>
<cite>The Article</cite>
</div>
N.B. If you google this issue you may come across an HTML5 Doctor article from 2013 that contradicts much of what’s laid out here. That said, every time it links to the docs for support, the docs agree with the article you’re currently reading rather than the HTML5 Doctor article. Most likely the docs have changed since that article was written.
Hey, what about the figure element?
One way to mark up a quotation — and in a way that pleases the semantic code deities — is to put the blockquote within a figure element. Then, put the cite element and any other author or citation information in a figcaption.
<figure class="quote">
<blockquote>
But web browsers aren’t like web servers. If your back-end code is getting so big that it’s starting to run noticably slowly, you can throw more computing power at it by scaling up your server. That’s not an option on the front-end where you don’t really have one run-time environment—your end users have their own run-time environment with its own constraints around computing power and network connectivity.
</blockquote>
<figcaption>
— Jeremy Keith, <cite>Mental models</cite>
</figcaption>
</figure>
While this doubles the number of elements needed, there are several benefits:
- It’s semantically correct for all four elements.
- It allows you to both include and encapsulate author information beyond citing the name of the work.
- It gives you an easy way to style the quote without resorting to divs, spans or wretchedness.
See the Pen
It Figures You’d Say That by CSS-Tricks (@css-tricks)
on CodePen.
None of this is for dialogue
Not <dialog>
! Those are for attention-grabbing modals. Dialogue, as in, conversational exchanges between people speaking or typing to each other.
Neither <blockquote>
nor <q>
nor <cite>
are to be used for dialogue and similar exchanges between speakers. If you’re marking up dialogue, you can use whatever makes the most sense to you. There’s no semantic way to do it. That said, the spec suggests <p>
tags and punctuation with <span>
or <b>
tags to designate the speaker and <i>
tags to mark stage directions.
Accessibility of quotes
From the research I’ve done, screen readers should not have any issue with understanding semantic-deity-approved <q>
, <blockquote>
, or <cite>
tags.
More “ways” to “quote”
You can add quotation marks to a <blockquote>
using CSS pseudo elements. The <q>
element comes with quotation marks baked in so they need not be added, however adding them as pseudo-elements can be a workaround for older browsers that don’t automatically add them. Since this is how modern browsers add the quotation marks there’s no danger of adding duplicate quotes. New browsers will overwrite the default pseudo elements, and older browsers that support pseudo elements will add the quotes.

But you can’t, like I did, assume that the above will always give you smart opening and closing quotes. Even if the font supports smart quotes, sometimes straight quotes will be displayed. To be safe, it’s better to use the quotes CSS property to up the intelligence on those quotation marks.
blockquote {
quotes: "“" "”" "‘" "’";
}
See the Pen
"Quot-a-tizing" the blockquote by CSS-Tricks (@css-tricks)
on CodePen.
Multi-level quoting
Now let’s look at quote levels. The <q>
tag will automatically adjust quote levels.
Let’s say you’re in an area that uses the British convention of using single quotes. You could use the CSS quotes rule to put the opening and closing single quotes first in the list. Here’s an example of both ways:
See the Pen
Quote Within a Quote by CSS-Tricks (@css-tricks)
on CodePen.
There is no limit to nesting. Those nested <q>
elements could even be within a blockquote that’s within a blockquote.
If you add quotation marks to a blockquote, know that the blockquote does not change the quote level the way a <q>
tag does. If you expect to have quotes within a blockquote, you may want to add a descendant selector rule to start <q>
elements within a blockquote at the single quote level (or double quotes if you follow British conventions).
blockquote q {
quotes: "‘" "’" "“" "”";
}
The last quote level you put in will continue through subsequent levels of quotation. To use the double, single, double, single… convention, add more levels to the CSS quotes property.
q {
quotes: "“" "”" "‘" "’" "“" "”" "‘" "’" "“" "”";
}
Hanging punctuation
Many typography experts will tell you that hanging the quotation marks on blockquotes looks better (and they’re right). Hanging punctuation is, in this case, quotation marks that are pushed out from the text so that the characters of the text line up vertically.

One possibility in CSS is using a slightly negative value on the text-indent
property. The exact negative indentation will vary by font, so be sure to double check the spacing with the font you end up using.
blockquote {
text-indent: -0.45em;
}
There is a nicer way to handle this by using the hanging-punctuation
CSS property. It’s only supported in Safari at the time of this writing, so we’ll have to progressively enhance:
/* Fallback */
blockquote {
text-indent: -0.45em;
}
/* If there's support, erase the indent and use the property instead */
@supports ( hanging-punctuation: first) {
blockquote {
text-indent: 0;
hanging-punctuation: first;
}
}
Using hanging-punctuation
is better because it’s less fiddly. It’ll just work when it can.
See the Pen
Hanging Your Punctuation by CSS-Tricks (@css-tricks)
on CodePen.
Can we animate quotation marks?
Of course we can.
See the Pen
Dancing Quotes by CSS-Tricks (@css-tricks)
on CodePen.
Why you’d need to do this, I’m not totally sure, but the quotation marks in a <q>
tag are added are pseudo elements in the UA stylesheet, so we’re able to select and style them — including animation — if we need to.
Wait, maybe we just solved the air quotes thing after all.
Just a note on the
q
element: We’ve had many a thread on this on the W3C end and some of them, notably because of Ian (Hickson), are quite instructive. See for example one 2004 thread on correct use ofq
, or Ian’s 2008 “omnibus”.I’ve during that time learned not to use
q
(and neither thequotes
property), and to recommend the same.Hi Jens,
Thanks for adding to the conversation. Could you expand on your problems with q and quotes?
It’s probably that I’m dense, but after reading your links I don’t see cut and dry reasons to avoid them, particularly since all modern browsers are now consistent in their handling of the q element. I see mention of internationalization issues (difficulty in supporting all languages), wishes for a different implementation, and discussion of how q’s been misused, but no discussion of why q should be avoided altogether. Your 2004 link says that q has caused harm, but I don’t see what that harm is or why it’s caused.
Assuming internationalization isn’t a concern for a particular website (arguable whether that shouldn’t be a concern for all websites), are there other issues that q creates? And what issues have you found with the quotes property?
Thanks!
The threads were examples, they’re probably hard to parse and there are probably more interesting ones. It may be worth a post on its own but in essence, for inline quotations it’s really not necessary to use extra markup (nor styling for that markup, as with
quotes
—use actual quotation marks). You can do it, yes, but it’s not worth the effort.(Just the summary for how I’d lay down the case with
q
andquotes
, a case which makes me curious to collect your points and reopen and reevaluate it.)The q tag can certainly be extra markup and it certainly isn’t required. As the spec says, quotation marks are just as valid. But like all HTML tags I view it more as a tool to be used when the job is right for it. If you want to style quotations a little differently or pull them out programmatically or use the cite attribute to reference the source or have automatic quote levels etc. then it’s the right time to use a q tag. If you prefer to type less (I usually do) or, as Knud points out in their comment, the quote’s going to be copied often, then a q tag’s probably not the right choice.
umm, I don’t like “Many modern browsers will automatically add quotation marks” this means if I select and copy some text to “quote” somewhere that isn’t html, I will have to manually insert all the quotation marks into the text again.
regarding
<q>
tag, the broswer will also adjut the quotation character depending of the language. For exameple here in French we use « guillemets » for quotations (and nested quotations), and it render very well.I noticed that, if the
lang
element is missing, Firefox will use the system language, Chrome will stick to english of some kind.The figure method looks dev-friendly and flexible in terms of content and layout, is it accessible?
I’m far from an accessibility expert, but since all tags are used semantically and there’s nothing funky or obfuscating beyond an additional tag or two, I’d venture to say that screen readers and other assistive technologies should be able to handle it. I would be more than happy to cede that opinion to an expert, though, if someone disagrees.
Thanks for pointing out the broken links in the article: cite and blockquote – reloaded they are now fixed. The W3C HTML Recommendation has not changed, just that some links to W3C HTML now redirect.
I believe the
<blockquote>
element lets you put its source material (such as its<cite>
) in a<footer>
inside it, but that’s just an alternative to your<figure>
pattern, which I quite also like.“The spec makes a point of saying that the URL can be surrounded by spaces.”
The spec is very unhelpful in this respect. If the page is being converted from LTR to RTL, or vice-versa, then spaces within an attribute value will often mess things up entirely. Outer spaces between a quote (single or double) and the content should be avoided. If spaces are of any use in an attribute, the chances are that coding is involved, in which case the space can be added, or some special character can be converted.
Unless one gains some specific semantic advantage by use of the q element, I propose using the hard-coded punctuation marks freely available on the keyboard. Curly quotes are easy enough to use (even nesting rules are purdy simple). And the one mark saves a lot of bandwidth over the brackets and slashes. (P.s., as a general rule, Don’t quote: be quotable.)