Solana Token Name, Symbol & Image Rules (2026)

A Solana token's on-chain name is capped at 32 bytes, its symbol at 10 bytes and its metadata URI at 200 bytes, all enforced by the Metaplex Token Metadata program in UTF-8 bytes rather than characters. There is no on-chain limit on the image at all, because the image is not on-chain: the mint stores a URI, and the JSON at that URI carries the picture. That is where the practical rules live instead — square, PNG, under a few hundred kilobytes, permanently hosted, and directly downloadable. Get all of it right in the transaction that creates the mint, because after update authority is revoked none of it can be changed.

Quick Facts

Unit matters more than the number here. Every one of those limits is a byte count, and I have watched a launch fail at the wallet-approval step because someone put four emoji and a word into a name that read as well under 32 characters.

The on-chain limits, read out of the program

These numbers get repeated across dozens of tutorials with no source, so here is the source. In programs/token-metadata/program/src/state/metadata.rs of the Metaplex Token Metadata repository:

pub const MAX_NAME_LENGTH: usize = 32;

pub const MAX_SYMBOL_LENGTH: usize = 10;

pub const MAX_URI_LENGTH: usize = 200;

Alongside them, in state/creator.rs, MAX_CREATOR_LIMIT: usize = 5. And the enforcement, in assertions/metadata.rs:

if data.name.len() > MAX_NAME_LENGTH {
    return Err(MetadataError::NameTooLong.into());
}

if data.symbol.len() > MAX_SYMBOL_LENGTH {
    return Err(MetadataError::SymbolTooLong.into());
}

if data.uri.len() > MAX_URI_LENGTH {
    return Err(MetadataError::UriTooLong.into());
}

flowchart LR
  A["Your input<br/>name / ticker / image"] --> B{"name ≤ 32 bytes?"}
  B -->|No| E1["NameTooLong<br/>transaction fails"]
  B -->|Yes| C{"symbol ≤ 10 bytes?"}
  C -->|No| E2["SymbolTooLong<br/>transaction fails"]
  C -->|Yes| D{"uri ≤ 200 bytes?"}
  D -->|No| E3["UriTooLong<br/>transaction fails"]
  D -->|Yes| F["Metadata PDA written"]
  F --> G{"Update authority<br/>revoked?"}
  G -->|Yes| H["Permanent. No field<br/>can ever change"]
  G -->|No| I["Editable via the<br/>metadata update tool"]

Worth noticing that these are checks on a Rust String. The Rust standard library documents String::len() as returning "the length of this String, in bytes, not chars or graphemes. In other words, it might not be what a human considers the length of the string."

Solana's own docs describe the same fields as "max 32 chars," "max 10 chars" and "max 200 chars." That wording is a convenient simplification and it is wrong for anything outside ASCII. Trust the program, not the doc comment.

There is a second consequence of the byte model that nobody mentions: Metaplex pads. The program's utils/mod.rs runs puff_out_data_fields, which pads each string out to its maximum with zero bytes. Your two-character ticker occupies the same ten bytes of account space as a ten-character one. Short names do not save you rent.

That last row is the one that catches people. Thirty-one characters, comfortably under 32, and it fails.

WHERE EACH FIELD ACTUALLY LIVES

  MINT ACCOUNT ─────────────────┐
  supply, decimals, authorities │
                                │
  METADATA PDA (on-chain) ──────┤   name    ≤ 32 bytes  ┐
  derived from the mint         │   symbol  ≤ 10 bytes  ├─ permanent once
                                │   uri     ≤ 200 bytes ┘  update authority
                                │                          is revoked
                                ▼
  OFF-CHAIN JSON (at the uri) ──┐   name, symbol, description
  Arweave / IPFS / CDN          │   image ──────────────┐
                                │                        │
                                ▼                        ▼
                          THE IMAGE FILE          wallets, DexScreener,
                          PNG, square              Jupiter, CoinGecko

The symbol: legal length versus sensible length

Ten bytes is the ceiling. Nobody should approach it.

The reason is display, not the chain. Wallets and charting interfaces render tickers in narrow columns and truncate what does not fit, so a ten-character symbol arrives at a trader's screen as a fragment. People also type tickers by hand into search boxes, and every extra character is another chance to mistype.

Alchemii's create form caps the symbol input at eight characters for exactly this reason, which is stricter than the chain and deliberately so. Look at what actually trades: BONK, WIF, USDC, JUP. Three to five characters, all of them.

There is a harder constraint above the display one. Jupiter's token verification documentation makes ticker collision an explicit criterion: "Ticker Uniqueness — ensures the token can be easily identified by traders without confusion with existing verified tokens." The same page notes that during application "warnings are shown if the ticker is already verified for a different contract address," and lists ticker conflict among the reasons a verified tag gets removed later. Picking a ticker somebody verified already is not illegal and not blocked — it just quietly caps how far your token can go.

The image: no on-chain rule, five downstream ones

Search "Solana token logo size" and you will get confident numbers with no citations. Here is the honest position: neither Metaplex nor Phantom publishes a required or recommended pixel size. The constraints that do exist are set by whoever renders your token.

Phantom documents formats rather than dimensions. Its supported media types page lists "JPEG, JPG, PNG, GIF, SVG, WEBP" for images and states that "Phantom doesn't support HTML files." Its fungible-token page explains the resolution order: for a fungible token it shows name, symbol and image, and "if a Fungible token has name and symbol fields present on both its on-chain Metadata Account and off-chain JSON file (linked via the on-chain uri field), Phantom will prioritize the on-chain fields." So the name in your JSON does not override the name on the mint. Only the image comes from the JSON.

Phantom also warns that display is not guaranteed. Its token best-practices page says that "if Phantom cannot find more metadata about that token, it will display the token as 'Unknown'," and that "tokens that do not meet certain signals may be hidden or shown with a warning indicator," evaluated with third-party security providers.

CoinGecko is the one consumer that publishes a number. Its logo update article, updated 30 August 2026, states: "The preferred size of the logo on our site is a 200x200 image in a PNG/JPG/WEBP format. A transparent background is preferred for your logo."

Solana Explorer sets a hard ceiling. It proxies off-chain images and JSON, and its proxy config sets a 4 MB default maximum content size and a 10-second timeout, with oversize fetches degrading to a "view original" fallback. It also blocks non-HTTP protocols and hosts resolving to private IP ranges.

Solscan requires accessibility rather than a size. Its integration docs state that "the link to download the logo must be publicly accessible and not private." A Google Drive share link is the classic failure here — it serves an HTML interstitial, not an image.

Put the four together and one file satisfies all of them.

ONE 512x512 PNG, SIX CONSUMERS

  512 x 512 PNG, transparent, ~120 KB
        │
        ├── Phantom wallet ......... any of PNG/JPG/GIF/SVG/WEBP     ✓
        ├── CoinGecko .............. prefers 200x200 PNG/JPG/WEBP    ✓ downscales
        ├── Solana Explorer ........ hard cap 4 MB, 10s timeout      ✓ 0.12 MB
        ├── Solscan ................ link must be publicly fetchable ✓ if hosted right
        ├── DexScreener ............ reads the URI in your metadata  ✓
        └── Jupiter ................ shown beside the ticker         ✓

  a 3 MB 2048x2048 JPEG passes only the first and the third.

The off-chain JSON: what actually goes in it

The on-chain record holds three strings. Everything else a wallet shows comes from the JSON at your uri. Metaplex's token standard page defines the Fungible standard — the one that applies to any token with decimals above zero, which is every memecoin — as carrying name, symbol, description and image, where image is "URI pointing to the asset's logo."

Solana's docs show the fuller shape that most tools emit:

{
  "name": "My Token",
  "symbol": "MTK",
  "description": "A description of the token",
  "image": "https://example.com/token-image.png",
  "external_url": "https://example.com",
  "attributes": [{ "trait_type": "Category", "value": "Utility" }],
  "properties": {
    "files": [
      { "uri": "https://example.com/token-image.png", "type": "image/png" }
    ]
  }
}

Two fields in there earn their place. external_url is where a token's own page goes, and if your token was created here that is its token page, which is a real indexed URL rather than a dead link to a landing page. And properties.files[].type is the MIME type — Metaplex's own creation guide warns to "make sure you set the mimetag type correctly otherwise Arweave will not know how to display your image."

Malformed JSON is worse than missing JSON. Solana Explorer's proxy returns a 415 on a malformed body, and Phantom falls back to displaying the token as "Unknown."

Test it before you sign

Five checks, each of which takes under a minute and each of which has burned a launch I have watched.

• Count the bytes, not the characters. In a browser console, new TextEncoder().encode("Your Token Name").length returns the number Metaplex will check. Under 32 for the name, under 10 for the symbol.
• Open your image URL in a private window. If it renders the file directly with no login page and no interstitial, Solscan and DexScreener can fetch it. If it shows a Drive viewer, they cannot.
• Open your JSON URL in the same window. It should return raw JSON, not an HTML page. Paste it into a JSON validator; a trailing comma is enough to break the render.
• Search your ticker on Jupiter. If a verified token already holds it, decide now rather than after launch — ticker conflict is on Jupiter's own list of reasons a tag gets removed.
• Decide on update authority before you sign, not after. Keeping it live is the only way to fix any of the above later. Revoking it is the stronger trust signal. Our guide on editing a Solana token after launch covers the trade-off properly.

Token-2022 is a different set of rules

Everything above describes the classic path: an SPL token with a Metaplex metadata account. Token-2022 can instead store metadata inside the mint account itself via the metadata extension, and there the length limits vanish.

The token-metadata interface source defines TokenMetadata with name, symbol, uri and an additional_metadata vector of key-value pairs, and contains no MAX_* constant at all. Solana's metadata-pointer guide explains why: "TokenMetadata is a variable length TLV extension," and "the mint account needs enough lamports to remain rent-exempt for the metadata being stored. If the metadata grows later, additional lamports need to be transferred to the mint account before the instruction that resizes it."

So the constraint changes shape rather than disappearing. Instead of a 32-byte ceiling you get a rent bill that scales with length. Longer name, more rent.

The catch is support. Not every venue handles Token-2022 mints identically, and a rejected mint means re-minting from scratch — which is why the great majority of memecoin launches, including every one that goes through the Alchemii creator, use the classic SPL path with a Metaplex metadata account.

Limitations

• No wallet publishes a required logo size. The 512x512 recommendation is derived from what downstream consumers do publish, not quoted from Phantom or Metaplex, neither of which states a number.
• DexScreener's logo spec is not in its public docs. Its documentation covers listing behaviour but not image dimensions; the figures circulating for its banner and icon come from the checkout form rather than a published spec, so treat them as observed rather than official.
• The byte-versus-character reading is inferred from source, specifically the Rust String::len() semantics plus the Metaplex assertions. No Metaplex document says "UTF-8 bytes" in those words.
• Nothing here covers NFT metadata, which uses different token standards, a creators array that actually matters, and royalty basis points this article only mentions in passing.
• Verification criteria change. Jupiter states explicitly that "exact threshold values are intentionally not published," so treat its requirements as directional.

FAQ

What is the maximum length of a Solana token name?

32 bytes, enforced on-chain by the Metaplex Token Metadata program. The constant is MAX_NAME_LENGTH = 32 in the program's state module, and the assertion that rejects a longer value returns the NameTooLong error. Note the unit: the check is on byte length, so 32 plain ASCII characters fit, but an emoji is four bytes and a CJK character is three, which means eight emoji fill the field completely.

How many characters can a Solana token symbol be?

10 bytes on-chain (MAX_SYMBOL_LENGTH = 10 in the Metaplex program), but almost nobody should use all ten. Wallets and charting sites truncate long tickers in list views, and traders type them by hand. Alchemii's create form caps the symbol field at 8 characters for that reason. Three to five is where every widely traded Solana token sits.

Are Solana token limits in characters or bytes?

Bytes. The Metaplex program is written in Rust, and its checks call String::len(), which the Rust standard library documents as returning the length in bytes, not characters or graphemes. In UTF-8 an ASCII letter is one byte, a common CJK character is three and most emoji are four. A name of eight rocket emoji is 32 bytes and exactly fills the 32-byte field.

What image size should a Solana token logo be?

Square, and 512x512 PNG is the safe default. Neither Metaplex nor Phantom publishes a required size, so the binding constraints come from downstream: CoinGecko states a preferred 200x200 PNG, JPG or WEBP with a transparent background, and Solana Explorer proxies off-chain images with a 4 MB size ceiling and a 10-second fetch timeout. A 512x512 PNG under a few hundred kilobytes satisfies every one of those.

Can I use emoji in a Solana token name?

Technically yes — the field accepts any UTF-8 — but two things argue against it. Each emoji consumes four of your 32 bytes, and Phantom's help documentation says tokens can be hidden or flagged for suspicious names or logos. Emoji also break exact-match search on aggregators, so people looking for your token by name may not find it.

What image formats do Solana wallets support?

Phantom's documentation lists JPEG, JPG, PNG, GIF, SVG and WEBP as supported image types, and states that HTML files are not supported. PNG is the safest choice: it handles transparency, every downstream lister accepts it, and it avoids the sanitisation that some explorers apply to SVG because SVG can carry embedded scripts.

Where should the image and metadata JSON be hosted?

Somewhere permanent and public. Metaplex's own documentation notes the JSON can be stored on a permanent solution such as Arweave to ensure it cannot be updated, and Solana's docs name Arweave, IPFS or a dedicated CDN, warning that if the URI becomes inaccessible wallets and explorers cannot display your metadata. The link also has to be directly downloadable — Solscan's integration docs require that the logo link be publicly accessible and not private.

References

1. Metaplex Token Metadata — state/metadata.rs — MAX_NAME_LENGTH, MAX_SYMBOL_LENGTH, MAX_URI_LENGTH and the account-size arithmetic.
2. Metaplex Token Metadata — assertions/metadata.rs — the length checks and the creator-count and basis-point assertions.
3. Metaplex Token Metadata — state/creator.rs — MAX_CREATOR_LIMIT = 5.
4. Metaplex Token Metadata — utils/mod.rs — puff_out_data_fields, which pads every string to its maximum.
5. Metaplex — Token Standard — the Fungible standard's field list.
6. Metaplex — How to create a Solana token — Arweave upload flow and the MIME-type warning.
7. Rust standard library — String::len — length in bytes, "not chars or graphemes."
8. Solana Docs — Metaplex token metadata — the field table and the off-chain JSON example, plus the hosting warning.
9. Solana Docs — Metadata pointer guide (Token-2022) — variable-length TLV metadata and the rent consequence.
10. Token Metadata Interface — interface/src/state.rs — the TokenMetadata struct with no maximum-length constants.
11. Phantom Docs — Token best practices — metadata resolution order, the "Unknown" fallback, and the trust-signal filtering.
12. Phantom Docs — Home tab: fungibles — the fields Phantom displays and the on-chain-first priority.
13. Phantom Docs — Supported media types — accepted image formats; no HTML.
14. Jupiter Docs — Token verification — ticker uniqueness, market-cap warnings, and removal reasons.
15. CoinGecko Support — How do I update my token logo — 200x200 PNG, JPG or WEBP, transparent background. Updated 30 August 2026.
16. Solana Explorer — metadata proxy config — the 4 MB content ceiling, 10-second timeout and redirect limit.
17. Solscan Docs — Update token details — the public-download-link requirement.

Every limit above is enforced at the moment you sign, and most of them are permanent afterwards. The Solana token creator validates the name, ticker and image against these rules before it builds the transaction, and uploads the image and JSON to permanent storage in the same flow. If a token you already launched has bad metadata and update authority is still live, the metadata update tool is the fix; if it is not, what you can and cannot change after launch explains what your options actually are.