SvelteKit Form Actions: How to Validate Forms Without Depending on JavaScript

A page may contain more than one form. For example, an account settings page could let users update their profile and change their password.

SvelteKit supports named form actions, allowing different forms to invoke different server-side functions.

In +page.server.ts:

import { fail } from "@sveltejs/kit";
import type { Actions } from "./$types";

export const actions: Actions = {
  updateProfile: async ({ request }) => {
    const formData = await request.formData();
    const displayName = String(
      formData.get("displayName") ?? ""
    ).trim();

    if (!displayName) {
      return fail(400, {
        profileError: "Display name is required."
      });
    }

    // Update the authenticated user's profile.

    return {
      profileSuccess: "Profile updated."
    };
  },

  changePassword: async ({ request }) => {
    const formData = await request.formData();

    const currentPassword = String(
      formData.get("currentPassword") ?? ""
    );

    const newPassword = String(
      formData.get("newPassword") ?? ""
    );

    if (!currentPassword || newPassword.length < 12) {
      return fail(400, {
        passwordError:
          "Enter your current password and a new password of at least 12 characters."
      });
    }

    // Verify the current password, then securely update it.

    return {
      passwordSuccess: "Password updated."
    };
  }
};

The corresponding forms can target their named actions:

<form method="POST" action="?/updateProfile">
  <label for="displayName">Display name</label>
  <input id="displayName" name="displayName" required />

  <button type="submit">Update Profile</button>
</form>

<form method="POST" action="?/changePassword">
  <label for="currentPassword">Current password</label>
  <input
    id="currentPassword"
    name="currentPassword"
    type="password"
    required
  />

  <label for="newPassword">New password</label>
  <input
    id="newPassword"
    name="newPassword"
    type="password"
    minlength="12"
    required
  />

  <button type="submit">Change Password</button>
</form>

These examples illustrate action routing and basic validation. The password action is not a complete password-change implementation: a real application must authenticate the user, verify the current password using its password-verification mechanism, apply its password policy, and securely update the stored password.

For named actions, remember that SvelteKit's page form result represents the most recent action result. If several forms share a page, structure the returned data and displayed messages so that errors from one action are not mistakenly shown beside another form.

Improve the Experience With Progressive Enhancement

A standard SvelteKit form works without JavaScript. However, a full-page form submission may feel less responsive than an enhanced form.

SvelteKit provides use:enhance for progressively enhancing forms that submit to page actions.

Add the following import to the page component:

<script lang="ts">
  import { enhance } from "$app/forms";
  import type { ActionData } from "./$types";

  let { form }: { form: ActionData } = $props();
</script>

Then update the form:

<form method="POST" use:enhance>
  <!-- Keep the existing form fields here. -->
  <button type="submit">Send Message</button>
</form>

The form still submits normally when JavaScript is unavailable. When JavaScript is active, SvelteKit enhances the submission by using a client-side request and updating the page with the action result.

By default, use:enhance handles common action responses, including updating the form result and applying the usual page invalidation behavior. You can provide a custom callback when you need to control the submission lifecycle, show a loading state, or customize the result handling.

Do not make essential validation or data processing dependent on use:enhance. Progressive enhancement should improve the experience, not change the fundamental correctness of the form.

Return Validation Errors From a Schema

As forms become more complex, manually validating every field can make server actions difficult to maintain.

A schema-validation library can centralize the rules and return structured errors. The following example uses Zod:

import { fail } from "@sveltejs/kit";
import { z } from "zod";
import type { Actions } from "./$types";

const contactSchema = z.object({
  name: z.string().trim().min(1, "Name is required."),
  email: z.string().trim().email("Enter a valid email address."),
  message: z
    .string()
    .trim()
    .min(10, "Message must contain at least 10 characters.")
    .max(2000, "Message cannot exceed 2,000 characters.")
});

export const actions: Actions = {
  default: async ({ request }) => {
    const formData = await request.formData();

    const result = contactSchema.safeParse({
      name: formData.get("name"),
      email: formData.get("email"),
      message: formData.get("message")
    });

    if (!result.success) {
      return fail(400, {
        errors: result.error.flatten().fieldErrors,
        values: {
          name: String(formData.get("name") ?? ""),
          email: String(formData.get("email") ?? ""),
          message: String(formData.get("message") ?? "")
        }
      });
    }

    const contact = result.data;

    // Persist the validated contact data.

    return {
      success: true,
      message: "Your message has been submitted."
    };
  }
};

Install Zod in the project before using this example. The schema validates the submitted values and produces field-level errors that can be displayed by the page.

Schema validation is particularly useful when several actions share the same rules. It also makes validation easier to test independently.

However, validation libraries do not automatically provide authentication, authorization, database transaction handling, or protection against abuse. Those concerns still belong in the application's server-side design.

Common Mistakes to Avoid

Relying Only on Browser Validation

Attributes such as required, minlength, and type="email" improve usability but can be bypassed.

Always validate untrusted input on the server before processing it.

Forgetting to Return Submitted Values

When a form fails validation, clearing every field forces users to repeat work.

Return appropriate values with the failure result and use them to repopulate safe fields. Avoid returning passwords, authentication tokens, or other sensitive values to the page.

Returning an Error Without Displaying It

A server action can correctly reject invalid input while leaving users unsure what went wrong.

Display field-level errors close to the relevant controls. Use an accessible status or error summary when appropriate, and ensure that error messages can be identified by assistive technologies.

Treating Validation as Authorization

A valid email address or password does not prove that a user has permission to perform an operation.

Check the user's identity and permissions before modifying protected resources. For example, a profile update should modify the authenticated user's account rather than trusting a user ID submitted by the browser.

Making the Form Depend on Client-Side JavaScript

A custom JavaScript submit handler may improve the interface, but it should not be the only path to the server action when no-JavaScript support is a requirement.

Start with a standard HTML form and add use:enhance when needed.

Advantages and Limitations

Best Practices for Production Applications

• Keep validation and business rules on the server.
• Use schema validation for complex forms with multiple fields.
• Preserve safe input values after validation failures.
• Never return passwords or secrets in action results.
• Check authentication and authorization before protected operations.
• Use parameterized database queries and safe output rendering.
• Add request-size limits, rate limiting, and abuse prevention where appropriate.
• Use progressive enhancement without making JavaScript essential.
• Test successful submissions, invalid input, missing fields, and server errors.
• Make error messages accessible and specific enough to help users correct their input.

Summary

SvelteKit form actions provide a server-side approach to processing HTML forms without requiring client-side JavaScript. They allow developers to validate submitted data, return structured errors, preserve safe input values, and process valid submissions through server-side application logic.

For simple forms, a standard POST form and a default action may be sufficient. For larger forms, named actions and schema-validation libraries can improve organization and consistency. The use:enhance directive can then add a more responsive experience without removing the form's no-JavaScript fallback.

The most reliable approach is to build a form that works with standard HTML first, enforce validation and authorization on the server, and add client-side enhancements only when they provide a clear benefit.