In HTML, span is a generic container for a word, phrase or other phrasing content. It gives you somewhere to attach a class, a language attribute or a script hook when no more meaningful element fits. By default, a span stays inline with the surrounding text. It does not make that text bold, colored or clickable on its own.
Think of a collection notice that says, “Collect your order from the side door.” You want the location to stand out without turning it into a heading or a separate paragraph. A span can wrap just those three words. The rest of the sentence remains ordinary paragraph text.

A span groups content without assigning it a particular meaning. The surrounding paragraph is still a paragraph; the wrapped location is not automatically an address, a warning or a link. You supply an attribute when you need one, then CSS or JavaScript can select that element.
<p>Collect your order from <span class="pickup">the side door</span>.</p>
The opening tag begins the wrapper. The closing tag ends it after “door,” leaving the full stop outside. This is a small boundary, but it decides which characters get styled. Forget the closing tag and later words may receive a style you intended for only the location.
The class name is pickup, without a dot in the HTML. A CSS class selector uses the dot. Put the following rule in your stylesheet or inside a style element in the document head:
.pickup {
color: #145545;
background-color: #e8f4ec;
padding-inline: 0.2em;
}
You should get dark green words on a pale green background. Remove the rule and the wrapper remains in the document, but the words look ordinary again. That is a useful first experiment: it separates the HTML grouping from its visual treatment.
Choose a class name for the content’s purpose. If the color changes next month, pickup will still make sense. A name such as green-text becomes misleading. Dartmouth’s CSS fundamentals notes explain this naming approach and the distinction between a reusable class and a unique identifier.
Save this document as pickup.html in a plain-text editor, then open it in your browser. It needs no downloaded fonts, JavaScript or server. There are three different decisions in the body: a styled location, a phrase marked as Spanish, and an important instruction.
<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Pickup instructions</title>
<style>
body { font-family: system-ui, sans-serif; line-height: 1.6;
margin: 2rem; color: #172331; background: #ffffff; }
.pickup { color: #145545; background: #e8f4ec;
padding-inline: 0.2em; }
</style>
</head>
<body>
<h1>Collecting your order</h1>
<p>Collect your order from <span class="pickup">the side door</span>.</p>
<p>Ask for <span lang="es">la caja</span>, meaning the box.</p>
<p><strong>Bring your order number.</strong></p>
</body>
</html>
Start by checking the location. Only “the side door” should have the green treatment. The Spanish phrase should remain ordinary-looking text. The order-number instruction will normally appear bold because it uses strong, not because every span is bold.
Now move the first closing span tag to just before the word “door.” Save and reload. You should see the background stop earlier. Move it back afterward. Changing a wrapper’s boundaries is a quick way to understand which content belongs to it.
Try a second paragraph with another pickup class. Both locations should get the same treatment. You do not need a new rule for every occurrence. An id is different: each identifier must be unique within the document, even if the elements happen to look identical.
For a larger site, keep shared rules in an external file instead of copying a style block into every page. Our guide to linking CSS to HTML covers the file connection and relative paths. The markup in the body can stay exactly the same.
Before adding a span, ask what the content actually is. If it is a heading, link, quotation or instruction of strong importance, HTML already has elements that express those jobs. A wrapper with an impressive class name does not supply the same meaning.
| Job | Usually choose | Reason |
|---|---|---|
| Style a neutral phrase | span with a class | A small hook without an added meaning |
| Group a generic layout region | div | Can contain paragraphs and other flow content |
| Convey strong importance | strong | Describes importance, not just weight |
| Stress a word | em | Marks emphasis within the sentence |
| Go to another page | a with href | Provides a real hyperlink |
| Run an ordinary action | button | Supplies native button behavior |
<p><strong>Bring your order number.</strong></p>
<p>Please collect it <em>today</em>, not tomorrow.</p>
<p>Track your parcel on the <a href="/orders/">orders page</a>.</p>
These fragments illustrate meaning. Bring your order number is important. Stressing today changes how the instruction is read. The orders link needs an existing /orders/ destination on your site. None of those tasks needs a span masquerading as another element. The difference lies not in how you style it, but in what message you send to your visitors.
A div normally starts a block; a span normally participates in a line of text. CSS can change that display behavior, but it does not change which child elements are allowed. Putting a paragraph inside a span is not repaired by giving the span display: block. Use a suitable container in the first place. Changing display also does not turn a neutral wrapper into a heading or a control.

A span can carry useful information even when you apply no styling at all. In an English paragraph, lang=”es” identifies a Spanish phrase. Here is the line from the complete example:
<p>Ask for <span lang="es">la caja</span>, meaning the box.</p>
The attribute applies to the wrapped phrase, not the whole paragraph. It does not translate the words. If the entire paragraph were Spanish, you could put lang on the paragraph itself and skip the extra wrapper.
Texas A&M University–Corpus Christi’s language guidance demonstrates using span when only part of a page changes language. Match the language code to the actual text; choosing a code because it produces a preferred voice defeats its purpose.
Language information can help assistive technology choose pronunciation. It is worth checking with the languages and voices available in your testing setup rather than assuming every combination sounds the same. Western Washington University’s language guide describes why identifying both page language and inline changes matters.
Inline does not mean “always on one line.” A long phrase inside a normal span can wrap across lines as the available width shrinks. The span does not insert a forced line break, but it also does not prevent normal text wrapping.
There is another common surprise: setting width or height on an ordinary inline span does not size it like a block. If you need a compact box within a line, such as a delivery-time label, inline-block is one option.
<span class="delivery-slot">9–11 am</span>
.delivery-slot {
display: inline-block;
min-width: 6rem;
padding: 0.25rem 0.5rem;
border: 1px solid #64748b;
border-radius: 0.25rem;
}
The time label now accepts a minimum width and has padding and a border. It remains part of the surrounding inline layout. There is no need to turn every styled word into an inline-block box, though. A phrase that should flow naturally through a sentence is often better left inline.
Large vertical padding on an ordinary inline box can overlap neighboring lines rather than neatly pushing them apart. Check more than the one line where you first added the style. A narrow window makes these problems easier to spot.
For a typeface change, use a class with the appropriate CSS font property. You can apply the class directly to an existing element if the whole element needs it. Our guide to changing fonts in HTML explains family choices and fallbacks. A span is useful only when you need a smaller target.

If the words remain unchanged, look at the element in the browser inspector. Is the class actually present? Does the selector match it? Check the stylesheet request before adding stronger selectors or important declarations. The problem might simply be a missing file.
| Symptom | Check |
|---|---|
| No color change | Class spelling, selector dot and stylesheet loading |
| Too many words styled | Position of the closing span tag |
| Width has no effect | Computed display value; normal inline boxes ignore width |
| Unexpected line break | A display override or a different surrounding element |
| Mouse works; keyboard does not | A clickable span used where a native link or button belongs |
Do not attach click behavior to a span just to avoid a button’s default appearance. You would have to recreate keyboard handling, focus and semantics. Style the correct native control instead. A neutral text wrapper should not accidentally become the only way to perform an action.
Keep wrapping restrained, too. If one class can be placed on an existing paragraph, adding three nested spans makes inspection harder without helping the reader. Remove a wrapper when it no longer carries a needed attribute or provides a useful selection boundary.
Not by default. It is inline. Text may still wrap naturally, and CSS can change the element’s display.
Yes, when their content remains valid. Close them in reverse order and keep a reason for each wrapper. You rarely need a separate span for every word.
A generic wrapper provides no automatic ranking benefit. Use clear content and meaningful elements. Do not replace headings or links with styled spans and expect search engines or readers to recover the lost structure.
Choose your answer, then open each explanation. The answers use native disclosures and require no custom article script.
Use strong for strong importance. CSS can control its appearance separately.
On the element enclosing that phrase. A span is useful when no existing element marks exactly that boundary.
No. CSS display does not change HTML content rules. Choose a suitable container.
The post What Is Span in HTML? Examples, CSS and Common Mistakes appeared first on HTML5 Doctor.
Every SaaS homepage I load right now tells me about AI. Agentic this, copilot that, models, intelligence, automation. I wanted to know whether any of it holds up once you go past the homepage. So I started counting the AI words on the front door of every provider in the catalog, then putting that count next to two numbers we already keep: the Kin Score, which measures the foundation of an API operation, and Agent Readiness, which measures whether an agent can actually find, understand and use what a company offers.
The count is deliberately dumb. One fetch of the homepage, strip the markup, count AI and its neighbors. It does not judge whether a company means it. It only measures how loud the front door is. That is the point. Loud is easy. What sits behind it is the part that costs money and time.
Out of roughly 19,000 providers with a homepage of their own, 113 say AI or its neighbors more than a hundred times on that one page. That is the loudest one percent of the catalog. Twenty-eight of those 113 score zero on Agent Readiness. Forty-five score under 25 on the Kin Score, while the median for the whole catalog is 17.7.
I picked seven of them, re-profiled every one this week so the numbers are current, and every one of them has AI in the domain name too:
| Provider | AI words on the homepage | Kin Score | Agent Readiness |
|---|---|---|---|
| Vals AI | 601 | 24.8 | 11.7 |
| Securiti | 175 | 22.6 | 17.3 |
| Enzai | 165 | 17.3 | 18.7 |
| IgniteTech | 161 | 13.4 | 0.0 |
| Concentric AI | 136 | 11.1 | 14.4 |
| Qualified Health | 121 | 7.8 | 0.0 |
| Klaimee | 113 | 17.0 | 0.0 |
Vals AI has the loudest front door in the entire catalog, 601 AI words on one page. IgniteTech, Qualified Health and Klaimee each put more than a hundred AI words in front of you and score zero on Agent Readiness. No machine-readable contract, nothing an agent can discover, nothing an agent can call. These are companies selling AI to you that have not made themselves usable by AI.
I want to be fair here. Some of these are good products, and a low score is not a verdict on whether the software works. It measures what a company has published for someone trying to integrate with it, evaluate it, or put an agent in front of it. That is exactly the thing a buyer needs, and exactly the thing missing.
Six of these seven companies entered our catalog the same way, from a venture portfolio page. Vals AI lists 8VC, a16z and Bloomberg Beta. IgniteTech lists Sapphire Ventures, Qualified Health lists Menlo Ventures, Concentric AI lists Homebrew, Klaimee lists Y Combinator and Enzai lists Seedcamp. I’m not saying that funding is a problem. I am saying the front door reads like it was written for the next round, not for the person who has to wire the thing into their stack.
When the language on the homepage is aimed at investors, the investment in the foundation tends to come later, if it comes at all. Documentation, an OpenAPI, a sandbox, pricing you can find, rate limits you can plan around, a status page, a changelog, an MCP server or agent card that matches what the API actually does. None of that shows up in a pitch deck. All of it shows up the first week you try to integrate.
This is not an argument that talking about AI is bad. Some of the loudest companies in the catalog are also the strongest. Only 12 of the 113 loudest providers clear 55 on the Kin Score and 40 on Agent Readiness, and they are worth looking at:
| Provider | AI words on the homepage | Kin Score | Agent Readiness |
|---|---|---|---|
| CData | 201 | 82.4 | 67.8 |
| Speakeasy | 85 | 72.2 | 47.6 |
| Kong | 82 | 70.2 | 43.5 |
| LambdaTest | 144 | 58.7 | 48.9 |
CData says AI more than any of the seven above except Vals AI, and it backs it with an exemplar Kin Score and an agent-ready rating. Speakeasy and Kong are quieter on the front door and further along behind it. The difference between these companies and the first table is not how much they talk about AI. It is whether they did the plumbing first.
If you are procuring SaaS right now, almost every vendor will tell you they are AI-native. That claim is free to make. What it costs to back up is visible, if you know where to look:
A vendor with a loud front door and a thin foundation is asking you to fund the gap. Your integration team will pay for the missing documentation. Your agent team will hand-build what an MCP server should have provided. Your procurement team will chase pricing and terms that should have been published. That is a real cost, and it does not show up in the demo.
The front door count is a loose instrument and it will stay that way. I’m going to keep it separate from the Kin Score on purpose, because it measures what a company says, not what it delivers. The value is in the gap between the two. We’re going to formalize that gap, flag AI in the domain name alongside the homepage count, and keep re-profiling the companies at both ends so the numbers are current when we use them.
I want to keep finding the CDatas, the companies whose front door matches what is behind it, and keep showing why they are worth your money. I also want to keep surfacing the ones where the front door is doing all the work. If you are one of the companies in the first table and you think we’ve missed something you publish, tell us. We will look, and if it’s there, the number moves. That is the whole point of keeping score.
One of my favorite moments in a recent conversation was someone discovering that APIs they are responsible for already had a score. They had never heard of the Kin Score. They looked up their company at the table, recognized their own APIs, and said they were going to go back, compare against their competitors, and use it while building some new services.
That is worth sitting with. Your APIs are being read and compared whether or not you asked. Increasingly it is agents doing the reading, on behalf of somebody choosing a vendor.
Here is the kind of comparison I would do, using SMS, where the tag page on APIs.io ranks 171 providers.
| Â | Sinch | Vonage |
|---|---|---|
| Kin Score | 71.5 | 71.3 |
| Agent Readiness | 56 | 41 |
| Contract Quality | 71 | 73 |
| Developer Ergonomics | 80 | 91 |
| Access Clarity | 50 | 45 |
| Operational Transparency | 84 | 100 |
| Contract Governance | 22 | 22 |
| Discoverability | 82 | 82 |
| Regulatory Posture | 39 | 21 |
Going by the headline, these two are tied. The facets show they are not the same at all. One is ahead on ergonomics and operational transparency, the other on regulatory posture and agent readiness. And they share the same soft spot in governance, which may tell you something about the category. These numbers come from the public provider pages on APIs.io, most of them scored on October 17, 2026. They will move, so click through for the current reading.
Then look at the top of the tag. Twilio is at 91.6 and Telnyx at 86.1. They show what the category leaders have decided is worth publishing.
A similar score to your rival can feel good. One person I spoke with said just that, while being clear it was not yet good enough. The score only sees what is public, so a competitor who sells differently may be right to look different. A score also says nothing about whether your product is better.
But if you are building new services right now, like the person who sparked this post, this is the cheapest moment to use it. It costs almost nothing to design in what the leaders in your category already publish, and a lot more to retrofit it.
You can do all of the above by hand on the site, or have an agent do it. Each of these is a REST operation and an MCP tool:
| Job | REST operation | MCP tool | Plan |
|---|---|---|---|
| See who is in your category | GET /tags/{slug} |
get_tag |
Free |
| Compare side by side | GET /compare |
compare_providers |
Understanding |
| Rank a category by a facet | GET /ratings |
find_ratings |
Understanding |
Paths are relative to https://apis.io/api/v1, and the MCP server is at https://apis.io/mcp. The developer area has getting started, the MCP setup and the plans.
Microsoft's latest Surface Pro tablets start just $50 apart. Here's how their performance, displays, portability, battery life, and accessories compare.
The post Surface Pro 12-Inch vs Surface Pro 13-Inch: Which Snapdragon X2 Tablet Should You Buy? appeared first on TechRepublic.