A character card is a structured list of fields, and the model sees most of them as part of its context every message. Understanding what each field does — and how much context it consumes — is the difference between a card that behaves consistently and one that drifts or wastes tokens. Here is the full field reference.
The core persona fields
name — the character's display name, substituted for the {{char}} placeholder throughout the prompt. Keep it short and consistent.
description — the main body of the persona: appearance, background, and defining traits. This is usually the largest field and the backbone of the character. Write it as clear declarative statements the model can rely on.
personality — a focused summary of temperament and behavior. Some frontends weight this separately from the description, so use it for the traits that should always be front-of-mind.
scenario — the situation the conversation starts in. It sets the scene and framing without dictating the plot.
The dialogue fields
first_mes — the greeting, shown when a chat begins. This single message does enormous work: it establishes voice, tone, and formatting, and the model tends to mirror it. A strong first_mes is one of the highest-leverage parts of a card.
mes_example — example dialogue, often delimited with <START> markers. These few-shot exchanges teach the model how the character speaks. They cost context tokens on every turn in some frontends, so keep them representative rather than exhaustive.
alternate_greetings — additional opening messages the user can swap between. A V2/V3 feature; great for characters with multiple scenarios.
The instruction fields
system_prompt — an optional instruction block that can override or supplement the frontend's default system prompt. Use it sparingly for behavior that must hold regardless of scenario.
post_history_instructions — instructions injected after the chat history, near the end of the prompt, where they carry extra weight. Useful for reinforcing a rule the model keeps forgetting.
The attribution and organization fields
creator and creator_notes — who made the card and any notes for users (recommended settings, content warnings). Notes are shown to humans, not usually sent to the model.
tags — categorization labels for browsing and search. They do not affect model behavior but help humans and platforms organize libraries.
character_version — a version string for the card itself, useful when you iterate on a character over time.
The structural fields
character_book — an embedded lorebook of keyword-triggered entries that inject world info only when relevant. This is how a card carries a whole setting without bloating every prompt; see our lorebook guide.
extensions — an open object where apps store their own data (emotion sets, scripts, platform IDs). Because it is app-specific, extension data may not survive conversion to a different platform.
assets (V3) — an array describing bundled images such as the avatar and expression sprites, addressed by URI inside the CharX archive.
Fields and context cost
Every field that gets sent to the model competes for the context window. description, personality, scenario, first_mes, and mes_example are typically always present; a lorebook adds entries only when triggered. If a character feels forgetful, the culprit is often a bloated card crowding out the actual conversation. Our guide on token efficiency explains how to trim without losing character.
What survives conversion
The core persona and dialogue fields map across every format, which is why conversion is reliable. The instruction and structural fields survive only when the target format has an equivalent — CharacterAI's flat definition has nowhere to put post_history_instructions, for instance. When you convert, expect the character to arrive intact and the app-specific extras to be trimmed to what the destination supports.