If a character keeps drifting, sounding generic, or acting out of character, the fix is almost always in the card, not in how you chat. The card is the persistent instruction the model reads before every reply, so its quality sets a ceiling on how good the character can be. Understanding its anatomy turns character creation from guesswork into something you can debug. This builds directly on How AI Character Creators Work.
The core fields
Identity
Name, age range, role, one-line concept. This anchors everything else. A crisp concept — “a retired stage magician who now runs a struggling bookshop” — does more than a page of loose facts because it implies personality, setting and voice at once.
Personality
Three or four concrete traits, ideally with tension between them. “Warm but guarded, curious to a fault, allergic to sentiment” gives the model behaviour to enact. Long adjective lists (“kind, smart, funny, caring, loyal…”) blur into nothing because they lack specificity and contrast.
Speaking style
The most under-used field and one of the most powerful. Describe sentence length, formality, humour, and verbal tics — then include one or two lines of example dialogue in the character's voice. Models imitate examples strongly, so a single sample line often does more than a paragraph of description. This is the heart of Character Voice & Tone.
Backstory
Only the load-bearing facts — the ones that explain current behaviour. Where they're from, what they do, one or two formative events. Every extra paragraph competes for attention and can crowd out more important instructions, so treat brevity as a feature.
Relationships and context
Who you are to the character, the current situation, and any relevant setting. This grounds the interaction and prevents the character from treating every message as a cold open.
Boundaries
What the character will and won't do, how they handle conflict, whether they stay in character. Explicit boundaries prevent awkward drift and interact with the app's own content filters, which are a separate layer — see Privacy & Age Verification.
These fields aren't just a convention — they're a published file format
The "identity, personality, speaking style, backstory, context, boundaries" breakdown above isn't just a teaching device. It roughly mirrors real, publicly documented fields in the character-card file formats that many roleplay and companion tools actually read and write. The most widely adopted version, known as Character Card V2, stores a card as a JSON object with three top-level keys — spec (set to chara_card_v2), spec_version (2.0), and a data object holding the actual card. Inside data sit the fields that correspond almost one-to-one with the anatomy above: name and description cover identity and backstory, personality and scenario cover personality and context, first_mes and mes_example hold the opening line and example dialogue that fix speaking style, and a dedicated system_prompt plus post_history_instructions field is where many tools place boundaries and standing instructions so they survive alongside — rather than inside — the freeform description. V2 also added alternate_greetings, an embeddable character_book (a character-specific lorebook), tags, creator, character_version, and an open-ended extensions object for app-specific data.
A newer revision, Character Card V3 (spec: "chara_card_v3", spec_version: "3.0"), keeps every V2 field for backward compatibility and adds support for multiple embedded images and emotion sprites, group-only greetings, a nickname field, creator notes in multiple languages, and creation/modification timestamps. It also introduces a container format called CHARX: a zip archive holding the card as a card.json file at its root alongside the character's image and audio assets in subfolders, referenced from the JSON via embeded:// paths. Outside of CHARX, both versions can still travel as a single PNG image with the JSON quietly base64-encoded inside a PNG text chunk — chara for V2, ccv3 for V3 — which is why a character "picture" downloaded from a sharing site is often also the entire card.
None of this changes how you should write a card, but it explains why the fields in this guide feel so consistent across apps: most tools are reading and writing the same underlying schema, even when their creator screens look completely different.
It also has a practical payoff: because the schema is public and shared, a card you write carefully in one field-based creator often exports cleanly and imports into a different app without you having to rewrite it from scratch. The fields that matter for behaviour — personality, system_prompt, mes_example — carry over even when the surrounding app rebuilds its own UI around them. That's also why a "bad" card doesn't magically improve by moving it to a different platform: if the personality field was a vague adjective soup or the example dialogue was missing in the original, the exported JSON simply reproduces that same weakness somewhere else. The fix is still the one in this guide — specific traits, real example dialogue, and boundaries stated plainly — not a change of app.
Anatomy at a glance
| Field | Job | Common mistake |
|---|---|---|
| Identity | Anchor the concept | Vague or generic role |
| Personality | Drive behaviour | Long, flat adjective list |
| Speaking style | Fix the voice | Describing but not showing it |
| Backstory | Explain behaviour | Over-long biography |
| Context | Ground the scene | Leaving it blank |
| Boundaries | Prevent drift | Contradictory or missing |
Principles that separate good cards from bad
- Specific beats generic: concrete details give the model something to act on.
- Consistent beats comprehensive: a short card with no contradictions outperforms a long one that fights itself.
- Show, don't just tell: example dialogue is worth more than description.
- Lean beats bloated: every line competes for attention, so cut anything that doesn't change behaviour.
Debugging a misbehaving character
When something is off, map the symptom to the field:
- Generic replies → weak or listy personality.
- Shifting voice → missing speaking style examples.
- Acting out of character → unclear boundaries.
- Forgetting who you are → thin context, or a memory issue covered in Memory & Continuity.
Putting it to work
Write the card lean, test it in a real conversation, and edit the specific field that's failing rather than piling on more text. This iterative loop is exactly the process in Building Your First Roleplay Character, and it pairs with the in-the-moment techniques of Writing Better Roleplay Prompts. To see well-built cards in a real product, our MusePick review examines a character-first app's creator, and our rankings compare how much control different apps give you over the card.
Related on CompanionRank
Building Your First Roleplay Character Character Voice & Tone MusePick ReviewFrequently asked questions
What is a character card?
A character card is the hidden system prompt that defines an AI persona — its identity, personality, speaking style, backstory, context and boundaries. The app sends it to the model before every reply, so its quality sets a ceiling on how consistent the character can be.
Why does a shorter character card often work better?
Everything on the card competes for the model's attention. A lean, consistent card with concrete traits and example dialogue usually outperforms a long one that contains contradictions or filler, which dilute the instructions that actually matter.
How do I fix a character that keeps breaking voice?
Add one or two lines of example dialogue in the character's voice to the speaking-style field. Models imitate examples strongly, so showing how the character talks fixes voice drift more reliably than describing it.