System Prompt vs User Prompt: What's the Difference? (2026)

A system prompt is a persistent instruction that establishes the model's role, behavior, rules, tone, and output format for the whole conversation. You set it once, and it shapes every response that follows. It answers "who is the model and how should it act?" rather than "what do I want right now?"

Typical system-prompt content: the assistant's persona ("You are a senior tax accountant"), hard rules ("Never give legal advice; always cite the IRS form number"), tone ("Be concise and formal"), and output format ("Respond in JSON with keys summary and steps"). Here is a minimal example:

``` You are a customer-support assistant for an e-commerce store. Rules: - Be concise, friendly, and professional. - Never promise refunds; direct refund requests to the returns policy. - If you don't know an answer, say so and offer to escalate. Format: 2-3 short sentences, no bullet lists. ```

A user prompt is the specific request or question on a single turn — the actual task you want done right now. It changes with every message and operates within the constraints the system prompt established. It answers "what do I want this time?"

Against the support system prompt above, a user prompt might be:

``` A customer writes: "My order #4821 hasn't shipped after 6 days. What's going on?" Draft a reply. ```

The model combines the two: the system prompt tells it to be concise, friendly, and to avoid promising refunds; the user prompt gives it the specific situation to respond to. Same system prompt, thousands of different user prompts.

Put durable, conversation-wide instructions in the system prompt: role, rules, tone, safety constraints, and output schema. These are things you don't want to repeat on every turn, and that should apply consistently no matter what the user asks.

Put the specific, changing request in the user prompt: the actual question, the data to process, the one-off formatting tweak. A common mistake is stuffing role and rules into every user message — that's repetitive and inconsistent. Another is putting per-task data in the system prompt — that bloats it and reduces flexibility.

Rule of thumb: if an instruction should apply to the whole conversation, it belongs in the system prompt; if it only applies to this one message, it belongs in the user prompt. For technique on writing both, the free DAIR.ai Prompt Engineering Guide and Learn Prompting are good references.

Use the system prompt for: role, persistent rules, tone, safety constraints, and output format — anything that should hold across the entire conversation. Set once.
Use the user prompt for: the specific task, question, or data for this turn — anything that changes message to message. Set every turn.

Both OpenAI and Anthropic expose the two roles in their chat APIs. The structure is a list of messages where one carries the system instruction and the rest are the user (and assistant) turns. Conceptually:

``` messages = [ { "role": "system", "content": "You are a concise SQL tutor. Explain, then show one example query." }, { "role": "user", "content": "How do I find duplicate emails in a users table?" } ] ```

Anthropic's Messages API takes the system instruction as a top-level system parameter rather than a message, but the concept is identical. See the OpenAI chat API reference and the Claude prompt engineering overview for the exact shapes.

System prompts often contain rules, business logic, or configuration that you may not want exposed. The OWASP Top 10 for LLM Applications lists this as a real risk: LLM07:2025 System Prompt Leakage, where an attacker coaxes the model into revealing its system prompt. The related and higher-ranked LLM01:2025 Prompt Injection covers attempts to override system instructions with malicious user input. See the OWASP LLM Top 10.

Two practical takeaways. First, never put secrets (API keys, passwords, raw credentials) in a system prompt — assume it can leak. Second, don't rely on the system prompt alone for security; treat user input as untrusted and enforce sensitive rules with real controls (authorization, validation, guardrails) outside the model, because a determined prompt-injection attack can try to override system instructions.