Let’s be honest: most apps aren’t impressive because of their fancy buttons or slick layouts. What makes them useful is the stuff you can actually do.
Think about it:
- A blog without a comment box? That’s just a PDF with nicer fonts.
- An online store without a checkout form? Nothing more than a digital catalog.
- A dashboard without settings? Basically a poster that updates itself.
👉 Forms are where your users get to talk back to your app.
Here’s the catch: in many frameworks, building forms feels like busywork. You end up juggling fetch() calls, event listeners, and custom validation code. Miss one tiny detail and your whole flow collapses. Worse, if JavaScript fails (or is disabled), the form stops working entirely.
SvelteKit flips this on its head. Instead of saying “let’s rebuild forms in JavaScript,” it says:
- Use the HTML forms you already know.
- They’re accessible by default.
- They keep working without JavaScript.
- They handle flaky networks gracefully.
Then, if JavaScript is available, SvelteKit quietly upgrades them with progressive enhancement so they feel as smooth as any SPA form.
That’s the secret sauce: you don’t start fragile and patch on resilience later. You start rock-solid, and only add extra sprinkles when you want them.
In this first part we’ll:
- Build a contact form that’s 100% HTML.
- Watch how the browser handles submission all on its own.
- See how SvelteKit slots into that flow with the special
formprop. - Call out some easy mistakes beginners make (and how to dodge them).
Later we’ll tackle validation, error handling, redirects, uploads, and even a mini project. But first, let’s pour the foundation.
Step 1 — Create the contact page
Here’s the simplest possible form you can add to a SvelteKit route.
📂 File: src/routes/contact/+page.svelte
// SvelteKit will inject a `form` object after submissions
let { form } = $props();
Contact us
{#if form?.message}
class="success">✅ {form.message}
{/if}
form { display: grid; gap: 0.6rem; max-width: 40rem; }
label { display: grid; gap: 0.25rem; }
.success { color: #0a7; }
That’s it — a real HTML form, with three fields and a submit button.
Notice the placeholder form?.message section at the top. It won’t show anything yet, but once we connect the server action in the next section, this is where success messages will appear.
Step 2 — Let’s dissect it line by line
It’s easy to gloss over a form, but each line does something important. Let’s unpack it.
This is the classic browser pattern. When the user submits, the browser takes every and that has a name attribute, packages their values, and sends them in the body of a POST request to the same URL (in this case /contact).
Think of the browser like a mail carrier: the envelope is the POST request, the input names are the addresses on each slip inside, and the values are the contents. Forget the name, and that slip never makes it into the envelope.
name="..." on inputs
Absolutely crucial. Without name, the value won’t be sent. Beginners often wonder why their server action isn’t receiving the field — nine times out of ten, it’s because they forgot to add name.
required and type="email"
These are built-in browser validation helpers. They give the user instant feedback and prevent obviously invalid submissions. But they are not security features. Anyone can bypass them with a custom request. Treat them as UX sugar, not as your guardrails.
let { form } = $props();
This line declares a prop called form. SvelteKit automatically passes this prop into your page whenever a form submission is processed by the server. Right now it’s undefined, but soon it will hold messages, errors, and even the previous values the user typed.
{#if form?.message}
This conditional block displays a success message only after the server action returns one. Before submission, nothing renders. After a successful action, you might get form.message = "Thanks, Alice!" and see the ✅ success line appear.
Step 3 — What happens when you click “Send”
Let’s trace the lifecycle without any JavaScript at all:
- User fills in the form and clicks Send.
- The browser collects the inputs into a
FormDataobject and issues aPOST /contact. - SvelteKit checks if there’s a server file called
+page.server.tsor+page.server.jsat that route. If it exists, it runs the appropriate server action. - That action can validate, save to a database, send emails, or return any data.
- SvelteKit then re-renders the page, injecting the returned data into the
formprop.
This all works without JavaScript. The cycle is HTML → HTTP → HTML.
And that’s the beauty: your form will work in browsers with JS disabled, on flaky mobile connections, or even in places where your fancy SPA logic might fail. Accessibility and resilience are built in from the start.
Step 4 — Easy mistakes to avoid ⚠️
Even this simple form hides a few pitfalls:
-
Forgetting
name→ The server never receives the input. Always double-check every input has aname. -
Trusting
required→ Good for user experience, useless for real security. Server validation is mandatory. -
Expecting no reload → At this baseline, a submission reloads the page. That’s normal and good. Later we’ll enhance it with
use:enhance. -
Putting logic in the client first → Resist the temptation to hook up
on:submitandfetch()right away. Let the browser and SvelteKit do the heavy lifting.
Step 5 — Try it yourself 🚀
Let’s get this running in your project. Hands on is the fastest way to learn.
I am sure by this time in the series, you are pro at trying stuff out, but just in case, run command npm run dev from terminal and then open http://localhost:5173/contact. You should see the contact form rendered.
Fill in some fields and click Send. Right now you’ll probably get a 404 or 500 after submit, or form might reload. That’s expected — we haven’t told the server what to do with the POST yet.
The important thing to notice is:
- The form renders fine.
- Submitting triggers a real POST.
- The browser reloads as part of that process.
This proves the baseline works: SvelteKit is listening, and your form is already “real.”
Adding Server Actions and Validation
Right now our contact form renders beautifully and sends a real POST request. But when you hit Send, the server just shrugs — it doesn’t know what to do with that POST yet.
Time to give the server some brains. In SvelteKit, this is done with server actions. Actions are special functions that run only on the server, respond to form submissions, and pass their results back into your page via the form prop.
This is where the magic happens: we can validate the inputs, return friendly error messages, and even save data to a database or send an email.
Step 1 — Create the server file
In the same folder as +page.svelte, add a file called +page.server.ts (or .js if you’re not using TypeScript). This file is where actions live.
📂 File: src/routes/contact/+page.server.js
// src/routes/contact/+page.server.js
import { fail } from '@sveltejs/kit';
// Simple helper to check email format
function isValidEmail(value) {
return /\S+@\S+\.\S+/.test(value);
}
export const actions = {
// Default action: runs when the form posts without ?/name
default: async ({ request }) => {
const formData = await request.formData();
// Extract values from
const name = String(formData.get('name') ?? '').trim();
const email = String(formData.get('email') ?? '').trim();
const text = String(formData.get('text') ?? '').trim();
// Collect errors
const errors = {};
if (name.length < 2) errors.name = 'Please enter your name (at least 2 characters).';
if (!isValidEmail(email)) errors.email = 'Please enter a valid email address.';
if (text.length < 10) errors.text = 'Message must be at least 10 characters.';
// If invalid, return errors + values
if (Object.keys(errors).length > 0) {
return fail(422, { errors, values: { name, email, text } });
}
// Pretend to save the message (DB, email, etc.)
// await db.messages.create({ name, email, text });
// Success: return a message
return { message: `Thanks, ${name}! We received your message.` };
}
};
Step 2 — Breaking it down
Let’s look closely at what’s happening.
-
export const actions
An object where each key is an action. Here we only definedefault. If your form didn’t specifyaction="?/something", it maps todefault. -
async ({ request })
Every action receives a parameter that includes the originalRequestobject. We pull it out to get the form data. -
await request.formData()
This gives you all the input values as aFormDataobject. It works exactly likenew FormData(formElement)in the browser. -
Extracting values
We grabname,email, andtext, trim them, and ensure they’re strings. This preventsnullfrom sneaking in if the field is missing. -
Validation
We build anerrorsobject. Each property matches thenameof a field. If the name is too short, we adderrors.name. If the email is invalid,errors.email, etc. -
fail(422, data)
The specialfailhelper tells SvelteKit:- The submission failed validation.
- The response should have HTTP status 422 (Unprocessable Entity).
- The
dataobject should be injected back into the page’sformprop.
-
Success case
If there are no errors, we return
{ message: ... }. That message is now available asform.messageinside the page.
This is the full round-trip: form → server → validation → form again.
Step 3 — Update the page to display errors
Let’s hook up the error messages and make sure the form preserves values after a failed submission.
📂 File: src/routes/contact/+page.svelte
let { form } = $props();
Contact us
{#if form?.message}
class="success">✅ {form.message}
{/if}
form {
display: grid;
gap: 1rem;
max-width: 40rem;
}
.field {
display: grid;
gap: 0.25rem;
}
label {
font-weight: 500;
}
input,
textarea {
padding: 0.5rem;
border: 1px solid #ccc;
border-radius: 0.25rem;
font-size: 1rem;
}
.error {
color: #c00;
font-size: 0.875rem;
}
.success {
color: #0a7;
margin-bottom: 1rem;
}
Step 4 — What’s new here
If you are typing along, you can choose to skip the style section, it is just meant to make the form look better than before.
-
novalidate
This disables the browser’s built-in validation popups. Why? Because we want to test and see our server-side errors clearly. In production, you can combine both if you want. -
value={form?.values?.name ?? ''}
This ensures the field is prefilled with what the user typed, even if validation failed. Without this, every failed submit would wipe out their input — incredibly frustrating. -
{#if form?.errors?.field}
Shows error messages right next to each field. This makes the form user-friendly and accessible.
Step 5 — The lifecycle now
Here’s the new flow:
- User submits.
- Browser sends POST → server action runs.
- Server validates.
- If errors:
fail(422, { errors, values })returns. -
If success:
{ message: "Thanks…" }returns.- SvelteKit re-renders the page with the returned object as
form. - Page shows either:
- SvelteKit re-renders the page with the returned object as
-
Inline errors while preserving what the user typed, or
-
A success message. (with form values cleared out)
The cycle is smooth and reliable, all with basic HTML forms.
Step 6 — Why preserving values matters
Imagine typing a 200-character support request, only to have it vanish because your email field had a typo. You’d be furious.
By returning values in the fail response, and feeding them back into each field, we avoid that frustration. The user just corrects the email and resubmits. This little detail makes forms feel professional.
Try it out
Test it at http://localhost:5173/contact:
- Submit without typing → error messages under each field.
- Enter a short name or invalid email → only that field shows an error.
- Enter valid values → page reloads and shows the success message.
Congratulations — you’ve now built a real, validated form that works without JavaScript and handles errors gracefully.
Step 8 — Recap
- We created a server action in
+page.server.ts. - It extracted form values, validated them, and returned either errors or a success message.
- We updated the page to display inline errors and preserve input values.
- We now have a complete form loop: submit → validate → feedback.
This is already production-ready in many apps. But we can make it even smoother with progressive enhancement — letting SvelteKit handle submissions via fetch when JavaScript is available. That’s what we’ll do next.
Progressive Enhancement, Redirects, File Uploads & a Mini-Project
At this point, we have a solid form foundation:
- Works with or without JavaScript.
- Validates data on the server.
- Shows inline errors and preserves what the user typed.
That’s already enough to ship. But with JavaScript enabled, we can do even better:
- Submissions don’t need to reload the whole page.
- We can show a loading state while waiting.
- We can redirect smoothly after success.
- We can even upload files or handle multiple actions from one page.
This is where progressive enhancement comes in. Instead of replacing the HTML form, we enhance it when JavaScript is available.
Step 1 — Meet use:enhance
SvelteKit ships with a helper called enhance from $app/forms. All you do is attach it to a form:
📂 File: src/routes/contact/+page.svelte
import { enhance } from '$app/forms';
let { form } = $props();
That’s it — one extra attribute.
What’s happening here?
Why does this matter?
- No flash or flicker of a reload.
- Scroll position stays put.
- Other interactive UI doesn’t reset.
- Errors and success messages feel instant.
- And your server code is unchanged.
This is progressive enhancement: keep the rock-solid baseline that works everywhere, and add smoothness when JavaScript is available.
💡 Pro tip: If you open DevTools → Network tab, you’ll still see a POST request fire off. That’s normal! The difference is that SvelteKit handles it with fetch and patches the page in place, instead of letting the browser throw everything away and reload from scratch.
Step 2 — Add a pending/loading state
Enhancement is cool, but users also need feedback while waiting. That’s where a custom callback comes in. The enhance function lets you intercept what happens around the form submission: you can flip flags, show spinners, scroll somewhere, even prevent the default update if you want.
📂 File: src/routes/contact/+page.svelte
import { enhance } from '$app/forms';
let { form } = $props();
let submitting = $state(false);
What’s happening here?
When you write use:enhance(fn), SvelteKit:
- Hooks into the form’s
submitevent. - Calls your function (
fn) right before it sends data to the server.
- That’s why we set
submitting = trueimmediately.- Your function returns another function — a handler that receives an
{ update }object once the server responds. - Calling
await update()tells SvelteKit: “okay, apply the server’s response to theformprop, just like a normal submission would.” - After that finishes, we set
submitting = falseto re-enable the button.
- Your function returns another function — a handler that receives an
Why this matters
- Without this callback, SvelteKit would still enhance the form, but you wouldn’t know when the request was “in flight.”
- With it, you can add loading indicators, disable buttons, or do anything else that makes the app feel alive.
- Errors and success still flow into
formautomatically — we’re just giving the user a friendly “Sending…” while they wait.
💡 Reminder: In this snippet we’re focusing only on the loading state. If you also keep the error-handling markup from earlier (form.errors, form.values), it continues to work alongside use:enhance.
Step 3 — Redirect after success
Sometimes you don’t want to stay on the same page after submission — for example, a contact form usually goes to a thank-you page. That’s the Post/Redirect/Get pattern.
📂 File: src/routes/contact/+page.server.js
Up to now, on success you probably had something like this in your server action:
// success: return a message
return { message: `Thanks, ${name}! We received your message.` };
👉 Replace that line with a redirect:
// success: redirect to thank-you page
throw redirect(303, '/contact/thanks');
Everything else in your action — validation, error handling, preserving values — stays exactly the same.
📂 File: src/routes/contact/thanks/+page.svelte
Thanks!
We’ll be in touch soon.
💡 Why 303?
Because it tells the browser: “This POST is complete, now do a GET on that page.” That avoids the classic “Do you want to resubmit this form?” warning if the user refreshes.
⚠️ Heads-up: In this demo we’re only focusing on the redirect. If your form submission fails validation (e.g. the message is too short), you won’t see error messages unless you keep the error-handling markup from earlier. So for now, make sure you submit valid data to see the redirect in action.
Step 4 — File uploads 📎
File inputs work just like any other input. The only difference is you need enctype="multipart/form-data" on the form. On the server, files arrive as File objects.
📂 File: src/routes/profile/+page.svelte
import { enhance } from '$app/forms';
let { form } = $props();
Upload your profile picture
{#if form?.uploaded}
class="success">✅ Upload complete!
{/if}
{#if form?.error}
class="error">⚠️ {form.error}
{/if}
.success { color: #0a7; margin-top: 1rem; }
.error { color: #c00; margin-top: 1rem; }
📂 File: src/routes/profile/+page.server.js
// src/routes/profile/+page.server.js
import { fail } from '@sveltejs/kit';
export const actions = {
default: async ({ request }) => {
const data = await request.formData();
const file = data.get('avatar');
if (!(file instanceof File)) {
return fail(400, { error: 'No file uploaded' });
}
// Example: read into memory (works for small files)
const bytes = new Uint8Array(await file.arrayBuffer());
// await storage.put('avatar.png', bytes);
return { uploaded: true };
}
};
How it works
- The form in
+page.sveltePOSTs to the server withmultipart/form-data. - The action in
+page.server.jsreceives the file as aFileobject. - If no file is uploaded → return
fail(400, { error: … }). - If the file is valid → return
{ uploaded: true }. - That response is passed into the
formprop, so{#if form?.uploaded}or{#if form?.error}show feedback to the user.
⚠️ Note: In this demo we’re reading the entire file into memory. That’s fine for small files, but for larger ones you should stream directly to disk or cloud storage.
Mini-Project: Profile Manager 👤
Time to bring it all together!
So far, we’ve learned about forms, validation, progressive enhancement, pending/loading states, redirects, and even file uploads. Let’s wrap those pieces into a mini-project: a profile manager.
Here’s what the app will do:
- Let a user fill in their name and bio.
- Let them upload a profile picture.
- If the form has errors → show them inline and preserve the values.
- If submission succeeds → show a “Profile updated” message and a live preview of the saved profile.
- While uploading → disable the button and show “Saving…” so users know something’s happening.
- And because we’re still using plain
underneath, it works with or without JavaScript.
Client page
📂 File: src/routes/profile/+page.svelte
import { enhance } from '$app/forms';
let { form } = $props();
let submitting = $state(false);
Edit your profile
{#if form?.success}
class="success">✅ Profile updated!
{/if}
{#if form?.url}
Preview
![]()
src={form.url} alt="Uploaded avatar" class="avatar" />
{form?.values?.name}
{form?.values?.bio}
{/if}
form { display: grid; gap: 1rem; max-width: 30rem; }
.field { display: grid; gap: 0.25rem; }
.error { color: #c00; font-size: 0.875rem; }
.success { color: #0a7; margin: 1rem 0; }
.avatar {
display: block;
margin-top: 1rem;
max-width: 200px;
border-radius: 0.5rem;
}
Server action
📂 File: src/routes/profile/+page.server.js
// src/routes/profile/+page.server.js
import { fail } from '@sveltejs/kit';
import fs from 'fs/promises';
import path from 'path';
export const actions = {
default: async ({ request }) => {
const data = await request.formData();
const name = String(data.get('name') ?? '').trim();
const bio = String(data.get('bio') ?? '').trim();
const avatar = data.get('avatar');
// Collect validation errors
const errors = {};
if (name.length < 2) errors.name = 'Name must be at least 2 characters.';
if (bio.length > 200) errors.bio = 'Bio must be under 200 characters.';
if (avatar && !(avatar instanceof File)) {
errors.avatar = 'Invalid file.';
}
if (Object.keys(errors).length > 0) {
return fail(422, { errors, values: { name, bio } });
}
let url = null;
if (avatar instanceof File && avatar.size > 0) {
try {
// Ensure uploads folder exists
const uploadDir = path.join('static', 'uploads');
await fs.mkdir(uploadDir, { recursive: true });
// Save file with a timestamp to avoid collisions
const filename = `avatar-${Date.now()}-${avatar.name}`;
const filePath = path.join(uploadDir, filename);
const bytes = new Uint8Array(await avatar.arrayBuffer());
await fs.writeFile(filePath, bytes);
url = `/uploads/${filename}`;
} catch (e) {
// Catch server-side issues (permissions, disk, etc.)
return fail(500, {
error: 'File upload failed. Please try again later.',
values: { name, bio }
});
}
}
return {
success: true,
url,
values: { name, bio }
};
}
};
How it works
-
Form POSTs with
multipart/form-data. - Validation runs on the server: name length, bio length, avatar sanity.
-
Errors → returned with
fail(422, …), displayed inline under each field. -
Valid submission → avatar saved into
/static/uploads/, URL returned. -
Enhancement (
use:enhance) ensures the form updates without reload when JS is enabled, while still working with reload if JS is disabled. - On success, the updated profile (name, bio, and uploaded image) is displayed immediately on the same page.
- If something goes wrong while saving the file (e.g. no write permission), the
try/catchensures users see a friendly error instead of a raw 500.
⚠️ Production notes
This demo is great for learning, but in real apps you’ll want to:
- Use proper storage (e.g. S3, Cloudflare R2, or a database), not just dump files in
/static. - Sanitize filenames to prevent unsafe paths.
- Limit file size and type to protect your server.
Step 7 — Best practices ⚠️
- Always validate on the server — never trust client-side input alone.
- Use
fail(status, data)to return validation errors and preserve form values. - Default vs named actions: use a single
defaultfor simple cases, or multiple named actions (?/create,?/delete) when one page needs more than one form. - After a successful POST, redirect with 303 (Post/Redirect/Get) to avoid the dreaded “resubmit form” warning.
- If you add a custom
enhancecallback, keep it small and always callupdate()so the server response is applied. - For file uploads: stream large files (pipe them directly to disk or cloud storage) instead of buffering them into memory.
- Consider rate-limiting expensive actions (like sending emails or heavy database writes) so a spammy user can’t overload your app.
Wrapping up 🎉
We started with the most boring form imaginable — plain old HTML. Step by step we layered on:
- Server actions with real validation.
- Friendly error handling that preserves what users typed.
- Progressive enhancement with
use:enhance. - Pending/loading states for optimistic UX.
- Redirects using the PRG pattern.
- File uploads (with previews!).
- A mini Profile Manager project that tied it all together.
This gives you the full picture of forms in SvelteKit: start with a rock-solid, accessible baseline that works without JavaScript, and then progressively enhance it into something that feels fast and modern when JS is available.
Your forms are now both robust and delightful — exactly what users (and developers) want. 🎉
Follow me on DEV for future posts in this deep-dive series.
https://dev.to/a1guy
If it helped, leave a reaction (heart / bookmark) — it keeps me motivated to create more content
Checkout my offering on YouTube with (growing) crash courses and content on JavaScript, React, TypeScript, Rust, WebAssembly, AI Prompt Engineering and more: @LearnAwesome
