Plain-English explanation

A character card is closer to a saved character specification than to an AI model. It tells a compatible chat interface who a character is and how a conversation should begin; the connected large language model still generates the replies. Importing the same card into a different frontend or pairing it with a different model can therefore produce noticeably different behavior.

Cards make characters portable between tools such as SillyTavern and some local or hosted character platforms. Compatibility is not absolute: applications can support different card versions, optional fields, or proprietary extensions.

What a card can contain

Common fields include a name, description, personality cues, scenario, opening message, and example exchanges. Those fields are assembled into the model's prompt, often alongside the user's persona, recent chat history, and a system prompt. Some formats can also reference a lorebook or world-information entries that are inserted only when relevant keywords appear.

The portrait is not the character's intelligence. In PNG-based exchange formats, structured card data may be stored as metadata inside an otherwise ordinary image; removing or recompressing that metadata can leave a viewable portrait that no longer imports as a card.

Adult-AI use

Character cards let users keep an original roleplay character separate from a particular interface or model provider. That supports backup, editing, and migration, and it helps distinguish character design from the model doing inference. A downloaded card may contain more text than its visible portrait suggests, so users should inspect unfamiliar cards and avoid treating community descriptions as trusted instructions.

Character card versus persona and memory

A card normally defines the character being portrayed. A persona usually defines the user within the roleplay. Neither is the same as character memory, which stores or retrieves facts learned during conversations. A card can provide initial facts and behavioral guidance, but it does not itself guarantee that a model will retain events from a long chat.

Limitations and safety

  • Portability has limits. Field mappings, token budgets, and prompt assembly differ between frontends.
  • A card is not a model. Quality, policy behavior, and context handling still depend on the connected model and service.
  • Identity claims need scrutiny. A card using a real person's name or likeness does not establish permission. Use original, self-owned, or properly licensed character material.

Put this concept into practice

Related terminology

Related database entities

Further reading