Field types

Each entry in the config’s fields array describes one input. Every field needs a name and a type. Most have a label, and many carry validation rules.

{ "name": "message", "type": "textarea", "label": "Your message", "rules": [{ "r": "required" }] }

The types

There are eight field types.

Type	Renders as	Value sent
text	Single-line text input	string
textarea	Multi-line text box	string
email	E-mail input with an e-mail keyboard and autofill	string
tel	Phone input with a numeric keypad and autofill	string
select	Dropdown, needs an options list	string
checkbox	Single checkbox	boolean (true or false)
date	Date value in YYYY-MM-DD	string
file	File upload	sent separately, see below

Note

The type only picks the input, so a phone gets the right keyboard and the browser can autofill. Checking the value is a separate job. email and tel do not validate on their own. Add the matching email or tel rule when you want the value checked, and it is always checked on the server. For numbers and URLs there is no special type: keep the field as text and let a rule do the checking.

Common options

Every field supports these:

• name (required) — the key used in submissions, emails and webhooks. Must be unique within the form.
• type (required) — one of the types above.
• label — the human-readable label. Also used as the column heading in the notification email.
• rules — an array of validation rules. See Validation rules.

Text inputs: text, textarea, email, tel

These all send a plain string. They also accept a placeholder:

{ "name": "company", "type": "text", "label": "Company", "placeholder": "Acme Inc." }

The email type renders as <input type="email" inputmode="email" autocomplete="email">, so phones show a keyboard with @ and . ready, and browsers can autofill a saved address. It does not check the value on its own. Add the email rule when you want the address validated:

{ "name": "email", "type": "email", "label": "E-mail", "rules": [{ "r": "required" }, { "r": "email" }] }

The tel type renders as <input type="tel" inputmode="tel" autocomplete="tel">, so phones show a numeric keypad and browsers offer to autofill the number. Add the loose international tel rule (6 to 15 digits) to check it. For a Poland-only site, use the stricter phone rule instead. See Validation rules.

A textarea gets special treatment in the notification email: it renders as a block below the table of values, with the label on its own line and the text underneath, rather than being squeezed into a table cell.

select

A dropdown. It must define a non-empty options array, and the submitted value has to be one of them (checked on the server, so it cannot be bypassed):

{
  "name": "topic",
  "type": "select",
  "label": "What is this about?",
  "options": ["Sales", "Support", "Something else"]
}

checkbox

A single checkbox, typically for consent. Its value is a real boolean. An unchecked box is sent explicitly as false, not left out.

To make a checkbox mandatory (the usual case for a consent box), give it the required rule. OctaForms understands that “required” on a checkbox means “must be ticked”:

{ "name": "consent", "type": "checkbox", "label": "I agree to the privacy policy", "rules": [{ "r": "required" }] }

When a checkbox records consent, the exact text shown to the visitor and their answer are stored with the submission as a consent snapshot. See Privacy & GDPR.

date

A calendar date, sent as an ISO string like 2026-07-08. Validation checks both the format and that the date is real, so 2026-02-30 is rejected. How the date picker looks and how the value is displayed is up to your theme.

file

A file upload. Files are handled differently from every other type, for good reasons:

• The uploaded file is not sent inside the fields object. It travels as a separate part of the request. Your integration needs to send it the right way. See Your own JavaScript for the transport details, or just use the JS helper, which handles it for you.
• The file’s type is detected from its actual contents on the server, never from its name or the browser’s claim. Executable files are always rejected.
• One file per field, for now.

You constrain uploads with rules specific to file fields: mimes (allowed types), maxSize (in megabytes), and maxFiles. See Validation rules.

{
  "name": "cv",
  "type": "file",
  "label": "Your CV",
  "rules": [{ "r": "required" }, { "r": "mimes:pdf,doc,docx" }, { "r": "maxSize:5" }]
}

Where uploaded files go and how they reach you is covered in Emails (the file is attached to your notification) and Webhooks (webhooks get the file’s name, type and size, never the bytes).

Honeypot fields

Any field can be turned into a spam trap by adding "honeypot": true. A honeypot is a hidden field that real people never fill in but bots often do. It is not sent to visitors as a normal field, is never stored, and takes no rules.

The one thing that matters is its name: pick something browsers will never try to autofill. Names like company, website, phone, email or name are risky, because a browser’s autofill can fill them for a real visitor and land their submission in the spam quarantine. The config validator warns you if you choose a risky name.

{ "name": "contact_reason_extra", "type": "text", "honeypot": true }

How to render a honeypot correctly, and what happens when one is tripped, is covered in Anti-spam.