Infobox: 2 Columns — Format, Rules and Examples
Use a two-column infobox to split one idea into two matched points, improve scanning and extraction, and avoid forced comparisons that weaken clear content.
A two-column infobox splits one idea into exactly two parallel points so a reader can understand the relationship at a glance. Use it when the pair is more useful side by side than buried in a paragraph: two responsibilities, two stages, two perspectives, or two complementary parts of one answer.
That rendered example is one infobox, one shared title, and exactly two items. Both items answer the same kind of question at comparable depth. The element does not claim the two needs are opposites; it shows that a useful brief has to account for both.
Why this element matters
Dense prose makes readers reconstruct relationships. In a sentence such as “A content brief must serve the reader by resolving a task and serve the business by supporting a qualified action,” the two responsibilities exist, but their boundaries are weak. A two-column infobox makes the shared subject visible once and gives each responsibility a named region. Readers can scan both headings, choose where to start, and compare the amount and kind of detail without rereading a compound sentence.
The psychological benefit comes from chunking: grouping related information into bounded units. The shared title tells the reader what stays constant, while the item titles show what changes. That hierarchy is especially useful when neither point should dominate. Ordinary prose naturally gives the first point more prominence and can make the second feel like an afterthought; matched columns signal equal editorial weight.
Machine extractability is the ability of software to isolate a content unit while retaining its meaning. A typed infobox exposes a parent topic and two explicit child items. A retrieval system can preserve the shared title, item titles, body text, and source order instead of guessing where one clause ends and the other begins. Each item must still be self-contained: “The business requirement is evidence that supports a qualified action” survives extraction, while “The other side” does not.
Structure does not rescue weak thinking. If the source contains one developed point and one sentence added for symmetry, the renderer merely makes the imbalance more obvious. Apply the element writing rules : write the full reasoning first, then choose this element only when the finished idea genuinely has two parallel parts. The element-specific rules on this page take precedence where they define its exact item mapping and limits.
When to use it
Use a two-column infobox when all four conditions are true:
- There is one clear parent idea that can title the whole box.
- The parent idea divides naturally into exactly two items.
- Both items perform the same information job, such as explaining a responsibility, stage, audience perspective, or dimension.
- Each item can be understood in roughly 30–90 words without a nested structure.
Good uses include “Before launch / After launch,” “Reader signal / Business signal,” “What changes / What stays the same,” and “Owner responsibility / Reviewer responsibility.” The labels should expose a real relationship. If the reader cannot finish the sentence “These belong together because…,” the grouping is probably decorative.
Near-miss cases matter because a two-column layout can make almost any pair look intentional. Do not use it for a single idea split at an arbitrary sentence break. Do not turn a list of four items into two long columns merely to save vertical space; source order and scanning become ambiguous. Do not use it for a detailed product comparison with multiple criteria, because a comparison table gives each criterion an explicit row. Do not use it for pros and cons when the number of points differs or when readers must weigh several trade-offs. Do not pair a definition with a promotional call to action: those blocks perform different jobs and do not deserve equal treatment.
The strongest warning sign is a label such as “Other,” “More,” or “Additional information.” Those labels reveal that the split follows available space rather than meaning. Return the content to prose, or find the actual distinction before using the element.
Where to place it
Place the infobox immediately after the paragraph that introduces the shared idea. The reader needs one sentence of context before encountering the split, but should not have to cross unrelated evidence or another subsection to reach it. After the box, continue with analysis, examples, or instructions that apply to both items.
It may sit directly below an H2 when the H2 itself supplies the parent idea and the infobox has its own more specific title. It may also follow a short definition when the two items explain dimensions of that definition. It must not appear between a claim and its citation, between a step and the condition required to complete that step, or inside an ordered list item. Those positions break relationships that should remain contiguous.
Do not place it beside another two-column infobox, comparison table, tab set, or pros-and-cons block. Adjacent parallel structures force the reader to decide which visual relationship matters and can create four apparent columns on wide screens. Insert explanatory prose between distinct structures, or combine the material into one better-suited table or section. Avoid placing it immediately before or after a two-column call to action; identical geometry can make editorial explanation look promotional.
Use no more than one two-column infobox in a short section. Repetition turns a useful contrast into page furniture. When a long article contains several genuine pairs, separate them under different headings and confirm that each pair has a distinct parent idea.
Anatomy
The anatomy contains one parent region and two repeated child regions. The screenshot should label semantic parts, not padding or color tokens, so the specification remains useful if the visual system changes.
- Outer boundary: Groups the parent title and both items as one editorial unit.
- Shared title: Names the idea that both items explain. It is not a third point.
- First item title and body: States the first member of the pair in complete, extractable language.
- Second item title and body: Answers the same kind of question with matched depth.
- Layout relationship: Uses equal-width columns when space allows and stacks item one before item two on narrow screens.
Borders, background, gap, radius, type scale, and breakpoint belong to the renderer. Authors control the content hierarchy and order, not visual tokens.
Design examples
There is one semantic element with four supported content and viewport variants. Variants change title handling or responsive presentation; they never change the requirement for exactly two items.
Default titled variant: Preferred for standalone use. A shared title names the parent idea, and both child items have concise titles.
Contextual-title variant: The immediately preceding H2 may act as the shared title. This is allowed only when no paragraph or component separates the H2 from the box and the infobox has an accessible name derived from that heading.
Compact variant: Use for two short definitions or responsibilities. Each body still forms a complete sentence; the layout does not become a pair of taglines.
Narrow-viewport variant: Items stack vertically. The order remains meaningful without references to “left,” “right,” “above,” or “beside.”
Icons are not a content variant. If the design system adds decorative icons, they use empty alternative text and do not replace item titles. If each item needs an informative image, use an image-oriented element instead of expanding this infobox contract.
Parameters
The parameter contract prevents the element from drifting into a generic grid. Values that describe meaning belong in authored content; responsive layout stays in the renderer.
| Name | Type | Required | Min/max | Default | Source |
|---|---|---|---|---|---|
title | Plain string | Conditional | 3–10 words; 80 characters maximum | None | First heading in the parent body; may be derived from the immediately preceding page heading |
items | Collection | Yes | Exactly 2 | None | Two nested item bodies |
item.title | Plain string | Yes | 2–7 words; 60 characters maximum | None | First heading in each item body |
item.content | Limited Markdown | Yes | 1–2 paragraphs; 30–90 words recommended, 120 maximum | None | Item body after its first heading |
item.link | URL and anchor | No | 0–1 per item | None | Inline item body content |
variant | Enum | No | default or compact | default | Parent attribute |
stackOrder | Ordered pair | Derived | Item 1, then item 2 | Source order | Document source; not an author attribute |
The title is required unless the immediately preceding document heading supplies the same parent topic and can label the container programmatically. Item bodies allow emphasis, inline code, and one useful link. They do not allow nested headings, tables, media, accordions, forms, calls to action, or another infobox.
Syntax and code examples
All three notations preserve the same parent title, two ordered items, item titles, and item bodies. The portable Markdown directive is the canonical source. The Hugo and WordPress forms are adapter contracts; their renderers must produce equivalent semantic HTML and responsive order.
Portable Markdown directive
:::infobox-2-columns
## A useful content brief answers two questions
::item
### What does the reader need?
State the question, decision, or task the page must resolve, including the context that changes the answer.
::
::item
### What does the business need?
State the qualified action the page should support, along with the evidence required to earn that action.
::
:::
The first parent heading maps to title. Each ::item maps its first heading to item.title and the remaining body to item.content. This exact two-item mapping overrides the general repeatable-item allowance in the base rules.
Hugo shortcode
{{< infobox-2-columns title="A useful content brief answers two questions" >}}
{{< infobox-item title="What does the reader need?" >}}
State the question, decision, or task the page must resolve, including the context that changes the answer.
{{< /infobox-item >}}
{{< infobox-item title="What does the business need?" >}}
State the qualified action the page should support, along with the evidence required to earn that action.
{{< /infobox-item >}}
{{< /infobox-2-columns >}}
The adapter uses named parameters only. It must reject a third item rather than silently wrapping it, and it must preserve the authored item order when the layout stacks.
WordPress block
<!-- wp:amicited/infobox-2-columns {"title":"A useful content brief answers two questions"} -->
<!-- wp:amicited/infobox-item {"title":"What does the reader need?"} -->
<p>State the question, decision, or task the page must resolve, including the context that changes the answer.</p>
<!-- /wp:amicited/infobox-item -->
<!-- wp:amicited/infobox-item {"title":"What does the business need?"} -->
<p>State the qualified action the page should support, along with the evidence required to earn that action.</p>
<!-- /wp:amicited/infobox-item -->
<!-- /wp:amicited/infobox-2-columns -->
WordPress should expose two fixed item slots rather than an unrestricted “add block” area. Editors can reorder the two items, but cannot insert an unrelated block between them or add a third column.
Examples
Good example
This works because the shared title establishes one idea, the time boundary creates a genuine pair, and both columns specify comparable measurement work. Each item remains meaningful when stacked or extracted independently.
Bad example
Improve your content
Write well: Create useful, authoritative, engaging content that your audience will love and search engines will reward.
Other things: SEO also includes technical work, links, conversion design, analytics, brand building, distribution, maintenance, and many more important activities.
This fails because the pair is artificial. “Write well” is a vague instruction, “Other things” is a miscellaneous category, and the second item contains far more scope than the first. The box implies equal, parallel concepts where none exist. Replace it with prose that defines the actual content objective, then use a list or separate sections for the distinct workstreams.
Schema markup and accessibility
A two-column infobox has no dedicated Schema.org type and does not create standalone structured data. Its text remains part of the enclosing Article, TechArticle, or WebPage when the page qualifies for that markup. Do not mark the two items as ItemList merely because there are two of them; the element represents a relationship, not necessarily a ranked or complete list. If an item independently contains a fact used elsewhere in structured data, the page-level schema policy governs that fact.
Semantic HTML should express one labeled container with two child sections. Use an aside only when the pair is complementary to the surrounding narrative; use a section when it is part of the main argument. Give the container an accessible name through its visible title and aria-labelledby. Each child title must be a real heading at the correct level, not bold text chosen for appearance.
Source order is the accessibility order. Keyboard navigation, screen readers, copy-and-paste, and narrow screens must encounter item one before item two. CSS may create columns but must not visually reverse them. Never refer to “the left box” or “the right box,” because those positions disappear when stacked. Color, icon shape, and background cannot be the only way to distinguish items. The design must support text zoom without clipping, horizontal scrolling, or overlapping columns.
Writing rules
Start by writing the parent sentence: “This idea has two parts: X and Y.” If that sentence is inaccurate, do not use the element. Give both item titles the same grammatical form—two nouns, two questions, or two time phrases—because parallel language makes the relationship immediately legible.
Use exactly two items. Keep each title to 2–7 words and each body to 30–90 words where possible, with an absolute maximum of 120 words. A difference of a sentence is acceptable; a 35-word item beside a 110-word item requires editing or a different structure. Each body should answer the same implicit question and use comparable evidence depth. Matched depth does not mean padding a short answer with filler.
Use direct, neutral language. State the distinction in the titles and explain its consequence in the bodies. Prefer “Before launch / After launch” to “First / Second,” because meaningful labels survive extraction. Avoid “either/or” unless the choices are genuinely exclusive, and avoid “versus” when the items are complementary.
Never put these inside the element:
- A third item, even if the renderer could wrap it.
- A multi-step procedure, long bullet list, data table, pricing grid, form, testimonial, or promotional banner.
- Independent H2 sections, nested infoboxes, tabs, accordions, video, or image galleries.
- Required legal text, safety warnings, source lists, or qualifications that apply to only one sentence outside the box.
- Two unrelated links designed to resemble competing calls to action.
If either item needs subheadings or more than two paragraphs, promote both items into ordinary page sections. If readers need to choose between the items, add decision criteria in prose or use a comparison or decision element; visual symmetry alone does not explain a choice.
Post types that use it
The postTypes frontmatter field is the source for this usage set. Each listed format has a natural two-part relationship, but none should include the element by default when the content does not form a genuine pair.
| Post type | Typical use | Recommended position | Common misuse |
|---|---|---|---|
| Ultimate guide | Two dimensions, responsibilities, or stages within one complex concept | After the paragraph that establishes the parent concept | Using repeated pairs instead of developing a clear section hierarchy |
| Concept explainer | Two complementary parts or two perspectives needed for understanding | After the definition and before detailed examples | Presenting loosely related facts as a complete model |
| A vs B comparison | One compact distinction before the full criteria comparison | After the comparison scope, before the detailed table | Replacing criterion-by-criterion evidence with two promotional summaries |
| Feature page | User responsibility and system behavior in one workflow | After the capability explanation | Pairing an evidence statement with an unrelated sales CTA |
| Solution page | Two coordinated workstreams or stakeholder outcomes | After the problem and approach are defined | Forcing several audiences into two generic segments |
| Documentation article | What the user configures and what the system does | Immediately before the relevant procedure | Hiding required sequential steps in parallel columns |
QA checklist
- One parent idea: The box has one clear shared subject that explains why both items belong together.
- Exactly two items: Source and rendered output contain two child items—never one, three, or an empty slot.
- True parallelism: Both items answer the same kind of question and use titles with parallel grammar.
- Matched depth: Neither item is a token counterweight or a miscellaneous catch-all; detail and evidence are comparable.
- Useful placement: The box follows its introducing context and does not separate a claim from evidence or a step from its requirement.
- Safe neighbors: It is not adjacent to another parallel grid, comparison component, or two-column CTA.
- Extractable wording: Parent and item titles name their subjects, and bodies do not depend on “left,” “right,” or nearby pronouns.
- Responsive order: Narrow layouts stack item one before item two without clipping, horizontal scrolling, or visual reordering.
- Accessible structure: The container has a visible programmatic label, child titles are real headings, and color or icons do not carry meaning alone.
- Content limits: Each body stays within two paragraphs and contains no nested complex component, procedure, or promotional control.
- Notation parity: Portable Markdown, Hugo, and WordPress preserve the same title, two items, bodies, and order.
- Schema restraint: No list or comparison markup is added unless the page content independently qualifies for it.
A reviewer should reject the element when any of the first four checks fails. Those failures indicate a conceptual problem, not a styling defect, and changing the width or decoration cannot repair them.
FAQ
The frontmatter FAQ entries answer the recurring implementation questions: the item count is fixed at two, depth matters more than identical word counts, detailed comparisons need a table, mobile preserves source order, and the element does not generate schema markup. Keeping these answers in structured frontmatter lets the academy template render the approved FAQ treatment without duplicating the content in the body.
More tutorials in this section
Ready to put it into practice?
Free check · 7-day trial · no credit card