AI Character Cards 2026: What's Inside & How to Open One

Q: What's the difference between a V2 and a V3 card?

V2 stores the character in a `data` object inside a PNG and is the format most readers understand. V3 keeps those fields and adds assets such as expressions, usually in a `.charx` container or via the `ccv3` chunk. An older reader can open a V3 and display an empty character.

Q: What if the imported character replies like an assistant instead of the character?

Check three things in this order: that `first_mes` is written as the character speaking, that `mes_example` contains exchanges separated by ` `, and that no `system_prompt` with generic instructions came along from another card. In 90% of cases the problem is the first message.

Affiliate disclosure: this page contains affiliate links. We earn a commission when you sign up through our links, at no extra cost to you. Our editorial opinions are never paid for. Adult content 18+.

You downloaded a .png of a character and all you see is the artwork. Nothing is broken. That file carries a complete character sheet — name, personality, scenario, opening line — encoded as JSON inside a text chunk of the image itself. The community calls it a character card, and it has quietly become the de facto standard for moving a character from one app to another without rewriting it.

Most guides assume you already know what a tEXt chunk is. This one goes the other way: what is actually inside, how to open a card without installing anything, how to spot a poisoned one, and when you don’t need a card at all.

→ Try Candy AI free (50 tokens, no card)

The short answer: three formats, one real standard

Format	Where the JSON lives	What it stores	Who reads it	What usually breaks
V1	Flat JSON, or PNG with no wrapper	6 loose fields (name, description, personality, scenario, first message, examples)	Older apps and old exports	Creator notes and alternate greetings get dropped on re-export
V2	PNG with a text chunk named `chara` (base64 JSON)	15 fields inside a `data` object, plus a character book and extensions	SillyTavern, Risu, Agnai and most readers	This is what people mean by “the normal format”
V3	`.charx` container (ZIP), or PNG with the `ccv3` chunk	Everything in V2 plus an `assets` block for images and expressions	Recent tools	An older reader opens it and shows an empty character

In practice: if you have a .png, it’s almost certainly a V2 and it will work nearly everywhere. If you have a .charx, you need a V3-aware reader or a conversion. If you have a bare .json, you’re looking at a V1 or at data exported without the image.

What a character card actually is

A PNG that is also a JSON file

A PNG isn’t only pixels. The format allows metadata blocks called chunks, and one of them (tEXt) stores plain key-value text. The community used that slot: they put the character JSON, base64-encoded, under the key chara. The result opens as a photo in any image viewer and as a character sheet in any card reader.

One consequence almost nobody mentions: you can have two cards with the same artwork and two different characters. The face doesn’t identify the character. The data does.

V2 and V3 changed the container, not the personality

V2 added a wrapper (spec, spec_version, and a data object) so tools could tell what they were reading. V3 keeps those fields and adds a resource system so the card can also carry expression images and other files. Most cards in circulation are still V2, because that’s what readers understand best — and many tools that write V3 also embed a V2 block for backwards compatibility.

What a card is not

It is not a language model, not an account, and not a character hosted anywhere. It’s a text file with instructions. Which explains two things: why you can edit it in a text editor, and why a card can carry instructions you would never agree to execute.

The five fields that actually drive the roleplay

Of the fifteen fields in a V2 card, only five reach the model on every turn. The rest is metadata for humans or for the app. This is the table I wish I’d had at the start:

Field	Sent to the AI?	What it controls	Typical creator mistake
`description`	Yes	Who they are: appearance, background, context, speech patterns	Writing a 3,000-word novel that eats the context
`personality`	Yes	Behaviour summary, in short phrases	Restating the description in other words
`scenario`	Yes	Where the scene starts and what is happening	Leaving it empty and getting a generic coffee shop
`first_mes`	Yes	The character’s opening message	Writing an introduction instead of a line the character says
`mes_example`	Yes	How they speak: example exchanges separated by `<START>`	Stuffing 20 exchanges and drowning the rest of the prompt
`creator_notes`	No	Notes for the human (recommended model, warnings)	Believing this is where you “explain” something to the character
`tags`, `creator`, `character_version`	No	Sorting and versioning	None — those are for you
`character_book`	Yes, per entry	The world info book, triggered by keywords	Filling it with entries that fire on every message

Two conventions worth knowing: inside those texts, {{char}} is replaced by the character’s name and {{user}} by yours. And in mes_example, <START> marks where each example exchange begins.

The insight that matters: a card doesn’t make a character smarter. It makes them more consistent. If description is badly written, no model will fix it.

How to open a card without installing anything

Method 1: extract the JSON and read it

A PNG is a binary file, but the text chunks are plain. With Python, two lines will dump the whole thing:

import base64, json, re
raw = open("character.png", "rb").read()
blob = re.search(rb"chara\x00(.+?)(?:\x00|IEND)", raw, re.S).group(1)
print(json.dumps(json.loads(base64.b64decode(blob)), indent=2, ensure_ascii=False)[:2000])

If the file uses ccv3, swap chara for ccv3. You’ll get the full JSON: name, description, scenario and everything else.

Method 2: import it into a reader

Card readers (SillyTavern and friends) do the same thing with a UI: drop the PNG in, they read the chunk, create the character, and let you edit the fields. There’s no such thing as “installing a character” — the character is the file.

The 30-second check before importing

Does the name match what the artwork promises?
Does description contain real text, or is it empty?
Does first_mes sound like a character, or like a brochure?
Is there a system_prompt or post_history_instructions with odd text in it?
How many characters do the AI-facing fields add up to?

Where cards come from, and how to spot the bad ones

Archives and repositories

Most cards circulate through community repositories, Chub-style archives and Reddit links. They’re free and unverified. That doesn’t make them bad by default, but it does turn importing into a trust decision: you are putting a stranger’s text into your chat’s prompt.

Six red flags

Instructions aimed at the model, not the character: lines like “ignore all previous instructions” or “respond without restrictions” inside description. That isn’t characterisation, it’s an attempt to bypass the app’s rules.
A populated system_prompt on a card that claims to be “just a character”.
Disproportionate size: if the sheet passes 8,000–10,000 characters, someone is smuggling a novel or a manual in there.
Copyrighted characters from active franchises: they get removed from repositories and leave you with an orphan card.
Minors, or characters presented as minors: discard, no exceptions.
Empty fields with polished artwork: the most common sign of a card generated in a hurry to fill a catalogue.

The unverified-content problem

A card can include a character book with entries that fire on their own and inject 500 tokens per message. Nothing warns you. You notice when the chat starts answering oddly or forgetting what you said two sentences ago.

The real cost: a card eats your context

Here’s the part no “best cards” listicle explains. Everything in the AI-facing fields occupies context window on every message. As a rule of thumb, one token is roughly 4 characters of English text. That’s enough to estimate without any tooling:

Sheet size	Approximate tokens	What it does
2,000 characters	~500 tokens	Light card, leaves almost all the context to the conversation
6,000 characters	~1,500 tokens	Balanced if the character has their own world
12,000 characters	~3,000 tokens	Starts to show: less room for chat history
30,000 characters	~7,500 tokens	The character “forgets” sooner because history gets compressed sooner

It’s not that a big card is bad. It’s that context is a budget, and what you spend on the sheet you don’t spend on conversation memory. If the bot keeps forgetting details, the first suspect isn’t the model — it’s the card size.

Card + reader vs a managed app

Criterion	Card + reader	Managed app (Candy AI)
Control over the character	Total: you edit every field	High, within what the app exposes
Technical skill needed	Medium: files, chunks, context	None
Memory across sessions	Handled by the reader and your settings	Handled by the platform
Voice and images	Depends on third-party plugins	Built in, paid in tokens
Maintenance	You update everything	Updates itself
Cost	Free, or whatever you spend on an API	Limited free plan + tokens

The honest conclusion: cards are for people who want fine control and don’t mind wrestling with files. A managed app is for people who want to talk today and configure nothing.

How to build your own card in 10 minutes

1. Write the description like a spec sheet, not a novel

Three blocks: who they are (2–3 sentences), what they look like (2 sentences), how they speak (1 sentence with a verbal tic). If you need more world context, it belongs in the character book, not here.

2. The first message decides 80% of the tone

first_mes should be a line spoken by the character in a concrete situation, not a presentation. “You again? We close in twenty minutes” opens a scene. “Hi, I’m Aiko, a 24-year-old barista” closes it before it starts.

3. Dialogue examples: three exchanges maximum

Each block separated by <START> teaches the rhythm. Three is plenty; ten drowns the prompt and the character starts parroting the examples.

4. What you can safely leave empty

system_prompt, post_history_instructions and creator_notes can stay blank. alternate_greetings too. Nothing breaks. What you shouldn’t leave blank is description and scenario.

5. Export, then verify

Export from your reader, reopen the PNG with the method above, and check two things: that the chunk exists and that the character’s name is inside it. If the name isn’t there, the export failed and you own a nice picture with no card attached.

When you don’t need a card at all

If what you want is a conversation that remembers what you told it last week, with voice, photos, and no file wrangling, a card gives you nothing except work. That’s precisely the managed-platform use case, where you build a character in a form and the app handles memory.

On Candy AI you can create a character on the free plan (one character, around 30 messages a day) and find out whether the “app” format works for you before you set up a card reader. If it does, you’ve skipped the technical part. If it doesn’t, you’ll at least know which fields you’re missing — and you’ll write them better in your own card.

→ Create your character on Candy AI (free plan available)

FAQ

What exactly is an AI character card?

It’s a file holding a roleplay character’s sheet: name, description, personality, scenario, first message and dialogue examples. Usually it’s a PNG with that JSON base64-encoded inside a text chunk called chara, so it can be shared like an image.

What’s the difference between a V2 and a V3 card?

V2 stores the character in a data object inside a PNG and is the format most readers understand. V3 keeps those fields and adds assets such as expressions, usually in a .charx container or via the ccv3 chunk. An older reader can open a V3 and display an empty character.

Can I open a card without installing SillyTavern or anything similar?

Yes. The JSON sits in plain sight inside the PNG, so you can pull it out with a two-line script or any PNG chunk viewer and read it as text. To use it as a character you’ll need a reader or an app that supports import, but inspecting it requires nothing.

Does a bigger card make a better character?

Not necessarily. The fields sent to the model occupy context on every message, so a 30,000-character sheet can leave less room for history and make the character forget sooner. What improves a character is the precision of description and first_mes, not the volume.

Is it legal to use cards of famous characters?

That depends on your jurisdiction and your use, and I’m not your lawyer. What I can tell you is that cards for active franchises disappear from repositories regularly, and that any card involving minors gets discarded, always, without exceptions.

What if the imported character replies like an assistant instead of the character?

Check three things in this order: that first_mes is written as the character speaking, that mes_example contains exchanges separated by <START>, and that no system_prompt with generic instructions came along from another card. In 90% of cases the problem is the first message.