Build contact, survey or scored forms. Validation is derived from the input props and every submission is stored.
Use Form for anything that needs to reach you as structured data instead of an email — contact requests, event sign-ups, surveys, or scored quizzes. Every submission is stored so you can review, export or connect it to a notification through the site's email settings, without writing backend code.
Validation rules come straight from the props on each FormField — mark a field required, set its type to email, and the browser blocks an invalid submission before it reaches the server. A typical setup is a contact form with a required email field and a message field, submitting to a slug you can inspect later in the Obelisk admin.
What a Form is good for
On a webshop, a Form covers anything that doesn't fit the checkout flow itself — a custom quote request, a sample request, or a "notify me when back in stock" signup tied to a specific product. On a portfolio or agency site, it's usually the project inquiry form, often with a budget range or timeline field so leads arrive pre-qualified instead of generic "hello" messages. On a professional services site, a scored form works well for an intake questionnaire that routes a lead to the right service tier based on their answers, before a human ever gets involved.
The most common mistake is asking for more fields than the conversion is worth — a newsletter signup needing only an email address loses visitors for every extra required field bolted on. The opposite mistake also happens: leaving fields optional that should be required, which fills the submissions list with incomplete entries that need manual follow-up to even be usable. Also make sure every field's type matches its actual content (an email field typed as plain text loses its built-in format validation) so bad data is rejected in the browser instead of arriving in your inbox.
Every input inside a Form should be wrapped in a FormField, which supplies the label, helper text and validation state consistently across the whole form. For forms with several logical groups of fields, consider pairing the Form with introductory text or a short Faq above it addressing why certain fields are required — reducing hesitation before a visitor starts filling it in.
Because validation runs through native browser input types and the required attribute, the Form works with keyboard-only navigation and screen readers without extra ARIA wiring, and every submission is stored server-side in the forms data rather than depending on a third-party form service or client-side-only storage that could lose data on a network hiccup.
<Form slug='contact'> <FormField name='email' required><Input type='email'/></FormField> <Button type='submit'>Send</Button> </Form>