A contact section has one failure mode and almost every site has it: the reader wants to reach a person and the page offers a form that goes somewhere invisible. The form is not the problem. The problem is that a form is a promise with no receipt, and a visible email address is a promise with one.
13 public components on 21st have "contact" in the name. The shapes are simple; the decisions are not.
The shapes
Contact Card by Efferd is the compact block with details, icons and a form, Contact Page by the same author is the full page with email, phone, office and social, and Contact by Ravi Katiyar is the section version.
Contact Cards is the personal-site row, built around a copy-email button rather than a form, and Contact Support Block by preetsuthar17 is the support variant with status.
Show the address
The single highest-value decision here. A visible email address, as selectable text, outperforms a form on almost every small site, for three reasons that have nothing to do with design.
The reader keeps a copy of what they sent. They can attach something. And they can tell that a human will see it, which a form cannot communicate.
The usual objection is scraping. Obfuscation costs more than it saves for most sites, and a plain mailto: link with the address as its text is what people expect. If volume is genuinely a problem, an alias you can rotate is a better answer than hiding the address behind JavaScript.
If you do use a form
The forms guide covers validation and error placement. Four things specific to contact.
Say what happens next. "We reply within two working days" is the sentence that turns a form from a void into a request. If nobody replies within two days, do not write it.
Confirm on screen and by email. Replacing the form with a confirmation is the minimum; a copy in the sender's inbox is what makes it real, per the waitlist guide.
Keep it to three fields. Name, email, message. Every extra field costs replies, and a dropdown asking someone to categorise their own problem costs more than it saves.
Protect it without a puzzle. A honeypot field and a rate limit stop most automated submissions. A visual challenge in front of a contact form is a barrier for the people you want to hear from.
The parts people forget
Response time, honestly stated. Either commit to one or say you read everything and reply when you can.
A route for the urgent case. If some contacts are time-sensitive, say which and where they go.
The physical details, where they are needed. An address and a company number are trust signals on a commercial site, and in some jurisdictions they are a legal requirement rather than a choice.
Structured data. ContactPoint on an organisation is another of the few genuinely useful schema types, for the same reason the team guide recommends Person: an answer engine asked how to contact a company reads exactly that markup.
Where else to look
The honest list, because the answer is not always us:
| Source | Best for | Trade-off |
|---|---|---|
A mailto: link | The highest-response option on a small site | No structure, no routing |
| A form service | Submissions in an inbox with no backend | A third-party endpoint and their branding |
| shadcn/ui | Form, Input and Textarea underneath | You wire the delivery |
| 21st | Contact cards, pages and support blocks | Quality varies by author, so preview before you take it |
Taking one
Every component page has a live preview and the code. Installing goes through the shadcn CLI against our registry:
That key comes from your 21st account, and installs require a membership. Set API_KEY_21ST once in your shell and the command works for anything in the catalogue.
Frequently asked
- Should a contact section show an email address?
- On most small sites, yes, and it usually outperforms a form. The reader keeps a copy of what they sent, can attach something, and can tell a human will see it. Obfuscation costs more than it saves; an alias you can rotate beats hiding the address behind JavaScript.
- What does a contact form need?
- A sentence saying what happens next and when, a confirmation both on screen and by email, three fields at most, and protection that is not a puzzle: a honeypot and a rate limit stop most automated submissions without turning away the people you want to hear from.
- How many fields should a contact form have?
- Three: name, email, message. Every extra field costs replies, and a dropdown asking someone to categorise their own problem costs more than it saves, because they usually pick wrong and you route it again anyway.
- Is contact schema worth adding?
- Yes. ContactPoint on an organisation is one of the few uncontroversially useful schema types, for the same reason Person is on a team page: an answer engine asked how to reach a company reads exactly that markup.