How the 'use server' Directive Works

The 'use server' directive marks an async function as a Server Function that client code can call. When client code calls it, React sends a serialized copy of the arguments to the server, runs the function there, and returns a serialized result. It is the bridge for mutations, not a way to mark Server Components.

Two places to put the directive

The directive can sit on a single async function, or at the top of a module to mark every export as a Server Function.

App.jsx

async function addToCart(data) {
  'use server';
  await db.cart.add(data);
}

A function-level directive keeps the function private to its module. The server still exposes it to client code through a reference, but only within the same file.

App.jsx

'use server';
 
export async function createNote() {
  await db.notes.create();
}
 
export async function deleteNote(id) {
  await db.notes.delete(id);
}

A module-level directive marks both exports. This form is required when client code imports the functions directly, because the import must resolve to a server reference at build time. The function-level form is for a Server Component that passes a function to a Client Component as a prop, while the module-level form exposes a small library of actions.

What happens when a function is called

Calling a Server Function from the client is a network request, even though the code reads like a normal function call.

The arguments must survive serialization, and so must the return value. React creates a server reference for the function and hands that reference to client code, so the client never receives the real implementation.

Call the function inside a transition so React can keep the interface responsive and expose a pending state. Forms wrap Server Functions in a transition automatically.

What can cross the wire

Server Function arguments and return values follow a serializable contract.

• Allowed: primitives, arrays, plain objects, Date values, FormData, Promises, and other Server Functions.
• Not allowed: React elements or JSX, plain functions, classes, class instances, null-prototype objects, and unregistered symbols.

A form submission passes FormData, which is why form actions are the natural fit. A function return follows the same serializable rules as props passed into a Client Component. React elements and JSX cannot cross the Server Function wire, because a Server Function deals in plain data rather than rendered output.

Rules and security

Server Functions are async by design, and they should be called inside a transition. Forms handle that automatically, so a form action already runs as a transition.

• Only async functions. The underlying call is always a network request.
• Server-side files only. The directive cannot run in client code.
• Mutations, not fetching. Frameworks process one action at a time and do not cache the return value.
• Untrusted input. Arguments are fully client-controlled, so validate and authorize every call.

Treat a Server Function like a public endpoint. Check the signed-in user, validate the data, and never trust that the client sent what the UI displayed.

Not the Server Components directive

A common mistake is reading 'use server' as the marker for a Server Component. Server Components have no directive; they are the default in a React Server Components app.

If a module must run in the browser, it gets 'use client'. If a function must be callable from the browser, it gets 'use server'. The two directives solve different problems.

For the full feature, see React Server Functions and Server Actions. For the client side of the boundary, see how the use client directive works. For the component model behind both, start with React Server Components Explained.