A tutorial explains how to install a command-line tool. It shows the command to type, then, right below it, what the terminal prints back: a success message, an error, a version number. Those two lines do not tell the same story, and HTML offers a different tag for each.
<samp> exists precisely to mark what the machine hands back: a program's output, an error message, a result shown by a system, never what the person typed and never the source code that produces that result.
Definition
<samp> (for sample output) wraps text presented as the literal output of a program or a computer system: a message printed in a terminal, an API response printed as an example, an error message reproduced in a piece of documentation.
Browsers render it in a monospace font by default, the same one used for <code>, which is exactly why the two get mixed up at a glance. The difference sits in meaning, not appearance: <samp> shows a result, <code> shows the text of the program itself.
Syntax and minimal markup
It is an inline element with no attribute of its own beyond the global ones. It is used alone for a short piece of output, or wraps a longer block inside a <pre> when the output spans several lines and needs to keep its spaces and line breaks.
<p>The command prints <samp>Connection successful</samp>.</p>Concrete example
Installation documentation often combines three tags on the same lines: what the user types, what the terminal answers, and the name of a file or command mentioned in passing.
<pre><kbd>npm install believemy-cli</kbd>
<samp>+ believemy-cli@2.4.0
added 12 packages in 3s</samp></pre>The typed input and the printed output look identical, both in monospace, yet they do not mean the same thing: one is an action taken by the user, the other a response from the system. A properly configured screen reader can lean on that distinction to announce the context, even though the visual rendering does not change.
Difference with <code> and <kbd>
Three tags look alike and are told apart by what they stand for: the text of the program, the action taken by the person using it, or the reply the program sends back.
| Tag | What it stands for | Example |
|---|---|---|
<code> | The source code itself, what is written in the program | fetch(url) |
| <kbd> | What the person types on the keyboard | npm install |
<samp> | What the program or system hands back | added 12 packages |
A common shortcut is to mark everything as <code> out of convenience, including the returned messages. It looks fine visually, but erases a piece of information: <code> says "here is code", while <samp> says "here is what that code produced", a distinction that matters to anyone reading the page word by word with a screen reader or extracting content from a documentation site automatically.
An error message shown on an application's screen, reproduced in an article or in documentation as an example, also belongs under <samp>: it is neither code written by a developer nor input typed by a user, it is output from the system, exactly like a terminal message.
Best practices
Reserve <samp> for text genuinely produced by a program or a system: command output, an error message, an API response. Do not reach for it just because you want text displayed in a monospace font, that purely visual role belongs to a CSS class, not to a semantic tag.
For output spanning several lines, wrap <samp> inside <pre> to keep spaces and line breaks exactly as they appear in the terminal. For a short piece of output sitting inside a sentence, <samp> alone is enough.
Frequently asked questions
Can <samp> be used for an error message shown in a graphical interface?
Yes, <samp> is not limited to terminals. An error message reproduced in documentation, whether it comes from a command line or a dialog box, is still output from the system and belongs under this tag.
Should <samp> or <code> be used for a return value inside a code example?
It depends on what the line represents. If it is part of the program, for instance a comment showing the expected value inside the code itself, <code> remains the right choice. If it represents what the program actually prints once run, <samp> fits better.
Does <samp> look any different from <code>?
No, both render in the same monospace font by default and look nearly identical. These are tags of meaning, not of style: the difference serves whoever reads the page's source code, a search engine, or a screen reader, not the appearance on screen.