HTML Code, Keyboard Input, and Sample Output Tags

HTML gives you several semantic tags for showing code, keyboard shortcuts, and program output: code, pre, kbd, and samp. This article explains what each tag means, when to use it, how they work together, and how to write accessible markup for technical content.

Quick answer: Use code for code fragments, pre for preformatted blocks, kbd for keyboard input, and samp for sample output. Combine pre with code for readable code blocks, and use all four to keep documentation semantic and accessible.

Difficulty: Beginner

You'll understand this better if you know: basic HTML elements, how text content works, and why semantic tags improve readability and accessibility.

1. What Are code, pre, kbd, and samp?

These four elements are part of HTML text content and each one represents a different kind of technical text.

code marks a fragment of computer code.
pre preserves whitespace and line breaks exactly as written.
kbd represents keyboard input or a user action typed on a keyboard.
samp represents sample output from a program or system.

They are semantic tags, which means they describe meaning rather than style. Browsers usually render them in monospace, but the real value is the information they add to the document.

2. Why These Elements Matter

Technical writing often needs to show commands, code snippets, shortcuts, and output. Using the correct element helps readers understand what kind of text they are seeing and gives assistive technologies better context.

These elements matter because they:

make documentation easier to scan;
preserve formatting where needed;
improve accessibility for screen readers;
separate code examples from ordinary prose;
help browsers and tools recognize special text.

If you use plain paragraphs for everything, readers may not know whether they should type, copy, or interpret a line as output.

3. Basic Syntax or Core Idea

Here is the minimal idea behind each tag. The syntax is simple, but the meaning is important.

Inline code with code

Use code when the code fragment is part of a sentence.

<p>Use the <code>code</code> element for inline snippets.</p>

This shows a short code phrase inside regular text without turning the whole paragraph into a code block.

Preformatted blocks with pre and code

Use pre when spacing and line breaks matter, and place code inside it for code semantics.

<pre><code>const message = "Hello, world!";
console.log(message);</code></pre>

The pre element preserves formatting, while code tells browsers and tools that the content is source code.

Keyboard input with kbd

Use kbd to show what the user should press.

<p>Press <kbd>Ctrl</kbd> + <kbd>S</kbd> to save.</p>

This makes the shortcut clear and easy to style consistently.

Sample output with samp

Use samp for output from a program, shell, or system message.

<p>The command returned <samp>Build completed successfully</samp>.</p>

This tells readers that the text is something they might see on screen after running a command.

4. Step-by-Step Examples

Example 1: Inline mention of a function name

When you mention a function or file name in a sentence, wrap only the technical token in code.

<p>Call <code>fetchUser()</code> after the page loads.</p>

This keeps the sentence natural while still identifying the token as code.

Example 2: Multi-line command output

For output that includes line breaks or indentation, use pre so the formatting stays intact.

<pre><samp>Name: Ada
Email: [email protected]
Status: Active</samp></pre>

In many cases, samp inside pre is a strong choice when the content is clearly output rather than source code.

Example 3: A keyboard shortcut with multiple keys

Each pressed key should be its own kbd element, which improves clarity and styling flexibility.

<p>Use <kbd>Alt</kbd> + <kbd>Shift</kbd> + <kbd>P</kbd> to open the command palette.</p>

That structure is easier to read than one long plain-text shortcut.

Example 4: A full code example with preserved indentation

Use pre and code together when indentation matters, such as HTML snippets or nested statements.

<pre><code><article>
  <h2>Welcome</h2>
  <p>This is a short example.</p>
</article></code></pre>

This is the standard pattern for readable code samples in HTML documentation.

5. Practical Use Cases

API documentation that shows short inline identifiers like function names, properties, or filenames.
Tutorials that include terminal commands and their resulting output.
Help pages that describe keyboard shortcuts for desktop apps.
Technical articles that need to preserve indentation in configuration files or HTML snippets.
Error documentation that quotes the exact text shown by a compiler, shell, or browser.

If you write docs, support content, or developer onboarding material, these tags will appear often.

6. Common Mistakes

Mistake 1: Using pre alone for code samples

pre preserves whitespace, but it does not say the content is code. Without code, the markup is less semantic and harder to target consistently.

Problem: This block preserves formatting, but it does not identify the text as source code.

<pre>
  <span>const total = 42;</span>
</pre>

Fix: Wrap the code in code inside pre.

<pre><code>const total = 42;</code></pre>

The corrected version is both readable and semantically accurate.

Mistake 2: Using code for keyboard shortcuts

code marks source code, not user input. A shortcut like Ctrl+S should be written with kbd.

Problem: This makes the shortcut look like code instead of a key sequence, which can confuse readers and assistive technologies.

<p>Press <code>Ctrl</code> + <code>S</code> to save.</p>

Fix: Use kbd for each key in the shortcut.

<p>Press <kbd>Ctrl</kbd> + <kbd>S</kbd> to save.</p>

The corrected version communicates that the text is something the user should press.

Mistake 3: Forgetting to escape angle brackets inside code

When you show HTML inside a code block, literal angle brackets must be escaped. Otherwise the browser may try to interpret the sample as real markup.

Problem: This example is not safe as displayed content because the browser can parse the tags instead of showing them as text.

<pre><code>
<div>Hello</div>
</code></pre>

Fix: Escape the sample text so it appears literally to the reader.

<pre><code>
&lt;div&gt;Hello&lt;/div&gt;
</code></pre>

The corrected version displays the HTML example instead of trying to render it.

7. Best Practices

Practice 1: Use code for meaning, not just appearance

Do not use code merely because you want monospace text. The tag should always represent actual code or a code-like token.

<p>The variable <code>userName</code> stores the current user name.</p>

This keeps your markup meaningful and easier to maintain.

Practice 2: Keep keyboard input granular

Wrap each key separately with kbd, especially in multi-key shortcuts. That makes the shortcut easier to style and clearer for screen readers.

<p>Save with <kbd>Ctrl</kbd> + <kbd>S</kbd>.</p>

Granular markup is more flexible than a single combined shortcut string.

Practice 3: Use pre only when spacing matters

Reserve pre for content where spacing, line breaks, or indentation are part of the meaning. For ordinary prose, pre can create awkward layout and unnecessary horizontal scrolling.

<pre><code>SELECT *
FROM users
WHERE active = true;</code></pre>

This is a good use of pre because line breaks help the reader understand the query structure.

8. Limitations and Edge Cases

code does not automatically add syntax highlighting. You need additional styling or tooling if you want colored tokens.
pre preserves spaces and line breaks exactly, which can cause overflow on small screens if the content is long.
kbd is a semantic hint, but browsers may render it differently, so do not rely on its default appearance alone.
samp is for output text, but it does not validate whether the content is actually system output.
Screen readers may announce these elements differently depending on the browser and assistive technology, so clear surrounding text still matters.

One common misunderstanding is that these tags are purely visual. They are not; they describe intent, and that intent improves machine-readable structure.

9. Practical Mini Project

Let’s build a small support snippet that teaches a shortcut, shows a command, and displays its result in a semantically correct way.

<article>
  <h2>Export Your Report</h2>
  <p>Press <kbd>Ctrl</kbd> + <kbd>P</kbd> to open the print dialog.</p>
  <p>Then run:</p>
  <pre><code>npm run export</code></pre>
  <p>You should see <samp>Export finished successfully</samp>.</p>
</article>

This example uses each element for the job it was designed to do: shortcut, command, and output.

10. Key Points

code marks a code fragment or technical token.
pre preserves formatting and is commonly paired with code.
kbd is for keyboard input, shortcuts, or user-entered keys.
samp is for sample output or system responses.
Escaping special characters is essential when showing code samples inside HTML.
Semantic markup makes documentation clearer and more accessible.

11. Practice Exercise

Write a short help card that tells the user how to save a file, shows the command to run, and displays a success message.
Use kbd for the shortcut, code for the command, and samp for the output.
Wrap the command in pre if it needs line breaks or indentation.

Expected output: The card should clearly separate what the user presses, what they type, and what they see.

Hint: Start with a heading, then one paragraph for the shortcut, one preformatted command block, and one output line.

Solution:

<article>
  <h2>Save Your Work</h2>
  <p>Press <kbd>Ctrl</kbd> + <kbd>S</kbd> to save the file.</p>
  <pre><code>git status</code></pre>
  <p>Result: <samp>Nothing to commit, working tree clean</samp>.</p>
</article>

12. Final Summary

HTML provides four closely related semantic elements for technical text, and each one serves a distinct purpose. Use code for code fragments, pre for preserved formatting, kbd for keyboard input, and samp for sample output.

When you combine these elements correctly, your documentation becomes clearer, more accessible, and easier to maintain. The key is to choose the tag based on meaning first and appearance second.

If you are building documentation or help content, practice writing a few examples with the correct tag for each kind of technical text. Once the distinction becomes natural, your HTML will be more semantic and much easier for readers to understand.