DexScreener Banner Size: 3:1, 1500x500 Max (2026)

The DexScreener banner — DexScreener calls it the Header — is a 3:1 rectangle with a minimum image width of 600px and a maximum file size of 4.5MB, accepting png, jpg, webp and gif. Upload it at 1500x500. That is not a preference; 1500x500 is the largest render DexScreener's image CDN will produce, and requesting anything wider returns an HTTP 422. The companion Icon field is a 1:1 square, minimum width 100px, same 4.5MB cap and same four formats, rendered no larger than 256px. Both fields live inside the paid Enhanced Token Info order form, and both require a token that DexScreener has already indexed — which means a live pool. Every figure here was read off the live form and CDN on 2026-08-04.

Page one for this query today is a merchandise spam domain, a Dribbble mockup, a YouTube video and one competitor page. None of them show their working. This page does.

Quick Facts

Asset	DexScreener's field name	Aspect	Upload this	Min width	Formats	Max file size
Banner	Header	3:1	1500x500	600px	png, jpg, webp, gif	4.5 MB
Logo	Icon	1:1	500x500	100px	png, jpg, webp, gif	4.5 MB
Token ad creative	Image	1:1	500x500	100px	png, jpg, webp	4.5 MB
Trending-bar ad creative	Image	1:1	500x500	100px	png, jpg, webp	4.5 MB
Social / link preview	— (generated)	40:21	not uploadable	—	PNG, 1200x630	—

Source for rows 1-4: the field help text rendered by the live order form at marketplace.dexscreener.com/product/token-info/order and /product/ad/order, read 2026-08-04. Row 5 was measured directly from six live token profiles the same day.

The five image slots, and which one people mean by "banner"

The confusion in this query is real, so it's worth separating the slots before quoting numbers at them. DexScreener has five distinct places an image can end up on a token, and only one of them is wide.

Header. The wide 3:1 strip at the top of a token's page. This is what everyone means by "DexScreener banner." It is a field in the Enhanced Token Info form.

Icon. The small square logo next to the ticker, in search results, on the trending board and in the mobile apps. Also an Enhanced Token Info field. If you never buy Enhanced Token Info, DexScreener may still pull an icon from your on-chain metadata or an external token list — the Metaplex token metadata layer is where that comes from, and it is the reason a token can show a logo with no header.

Token Advertising creative. A paid ad unit. Square, 1:1, and despite the product page describing what "your banner" will earn in impressions, the uploader is the same square component the icon uses.

Trending Bar Advertising creative. Also square. Its title field is capped at 10 characters, which is a good hint at how small the unit is.

The social preview. Generated, not uploaded. Covered below.

So: if you searched "dexscreener banner size" and you meant the wide strip, you want the Header spec. If you meant an ad slot, you want a square. Getting this wrong costs a resubmission, and DexScreener's published refund policy explicitly excludes "if you are unsatisfied and want to cancel an order that has already been completed" — so an order that went through with the wrong artwork is your problem, not theirs.

The banner (Header) spec sheet

Verbatim from the four bullets DexScreener renders under the Header field on 2026-08-04:

• 3:1 aspect ratio (rectangle, for example 600x200px or 1500x500px)
• min. image width: 600px
• support formats: png, jpg, webp and gif
• max. file size: 4.5MB

The file input behind it declares accept="image/png,image/jpg,image/jpeg,image/webp,image/gif". Note image/jpeg is in the accept list even though the help text only says "jpg" — a .jpeg extension will not be blocked by the picker.

Three things the bullets do not say, which matter more than the bullets:

1500 is a ceiling, not a suggestion. DexScreener's image CDN takes explicit width and height parameters, and it rejects anything outside a fixed allowlist. Requested against a live header asset today:

Requested	Response
300x100	200 OK
600x200	200 OK
900x300	200 OK
1500x500	200 OK
1501x500	422 Invalid image size: 1501x500
150x50, 450x150, 750x250, 1050x350, 1200x400, 1350x450	422 Invalid image size

Four sizes. Nothing between them, nothing above them. Uploading a 3000x1000 masterpiece buys you exactly the same 1500x500 render as a 1500x500 file, at several times the upload weight — and weight is the constraint that actually fails submissions.

Under-sizing is the more common mistake, and it's invisible until you look. The CDN downscales but does not upscale. I pulled twelve token headers from DexScreener's public token-profiles API and asked each for 1500x500. Eight returned a true 1500x500. Four returned 1023x341, 1014x338, 900x300 and 1281x427 — because that is all the pixel data their owners uploaded. A third of a live sample is shipping a header that cannot fill DexScreener's biggest surface, and none of those four projects will ever see an error message about it.

Off-ratio images are cropped, not letterboxed. The CDN's resize parameter is fit=crop. Asking a 3:1 header asset for a 64x64 square returns a real 64x64 image, not a padded one. Since all four legal header renders are exactly 3:1, a 3:1 source is never cropped — but a 16:9 file you resized by eye will be. Keep your wordmark off the edges.

The render ladder: what DexScreener actually serves

Two different image paths serve token assets, and they do not agree on sizes. Measured today:

Path	Slot	Sizes served
cdn.dexscreener.com/cms/images/<id>	Header	300x100, 600x200 (bare default), 900x300, 1500x500
cdn.dexscreener.com/cms/images/<id>	Icon	64x64, 128x128, 160x160, 256x256 — and 200x200 if you pass no parameters at all
dd.dexscreener.com/ds-data/tokens/solana/<mint>.png	Icon	64x64 (default and sm), 128x128 (md), 192x192 (lg/xl)
dd.dexscreener.com/ds-data/tokens/solana/<mint>/header.png	Header	300x100 (sm), 600x200 (default and md), 900x300 (lg), 1500x500 (xl)

The two paths do not even take the same parameters. The cms/images path wants explicit width and height integers and throws a 422 for anything off the allowlist. The ds-data path wants a named tier — ?size=sm, md, lg, xl — and quietly falls back instead of erroring: ?size=xxl on a header hands back the 600x200 default, and any unrecognised value on an icon hands back 64x64.

Two things fall out of the table. First, the header ladder agrees across both paths, so 1500x500 is safe advice regardless of which surface a trader hits. Second, the icon ladder does not — one path tops out at 256, the other at 192, and the bare cms/images icon URL with no parameters at all returns a 200x200 that you cannot request explicitly (asking for width=200 returns a 422). That is a mild inconsistency in DexScreener's own infrastructure and it is why I recommend 500x500 for the icon rather than trying to hit a native size. There is no native size to hit.

Token logo (Icon) spec sheet

Verbatim from the live form:

• 1:1 aspect ratio (square, for example 100x100px or 500x500px)
• min. image width: 100px
• support formats: png, jpg, webp and gif
• max. file size: 4.5MB

Same accept string as the header, gif included. The 100px minimum is a floor, not a target — a 100x100 file cannot fill the 128, 160 or 256 renders and will look soft everywhere except the smallest surface. 500x500 clears every render with room to spare and costs almost nothing in file size.

Worth knowing: the Icon field here is separate from the token image in your on-chain metadata. If DexScreener is showing the wrong logo or no logo and you have not bought Enhanced Token Info, the problem is upstream — the Metaplex metadata URI or the file it points at. The token image not showing diagnostic walks the five causes in order, and editing a token after launch covers whether you still hold the update authority you would need to fix it. Set the image correctly at mint and you skip both problems: alchemii's create flow writes the metadata during creation, and the metadata updater handles corrections afterwards.

Animated GIF banners: they work, and the ceiling is weight

"dexscreener gif banner size" is a real query with a real answer, and the answer is not in any documentation. So I measured it.

The Header field accepts image/gif, and animation survives the pipeline intact. Of 28 boosted-token headers surveyed on 2026-08-04, three were served as image/gif rather than a flattened jpeg or png. Frame counts on those three: 59, 49 and 50. Nothing is being stripped.

What bites is file size. Served payloads for one 59-frame animated header:

Render	Served bytes
600x200	1.8 MB
900x300	4.1 MB
1500x500	2.7 MB

Those are re-encoded served payloads, not the file that was uploaded — the 4.5MB cap applies to your upload, and DexScreener's encoder gets a second say afterwards. But the two track each other closely enough that the shape of the problem is clear: a 59-frame loop at full width lands in the same megabyte range as the cap, with no headroom to spare. The served sizes are not even monotonic in dimensions — the 900x300 render came back heavier than the 1500x500 one, which suggests different encoder settings per size rather than a simple rescale. Do not budget by intuition here. Export, check the byte count, and if you are over, cut frames before you cut resolution — a 20-frame loop at 1500x500 reads better than a 60-frame loop at 700px wide that DexScreener will never render above its source width.

One more data point from the same survey: the other two animated headers both capped at 600x200 no matter what size was requested — asking for 900x300 or 1500x500 returned a byte-identical 600x200 file. Their owners uploaded 600px-wide GIFs, probably because 600 is the stated minimum and it was the easier number to hit. Both are permanently a third of the resolution they could have been.

Where you actually upload these

Both image fields live in one place: the Enhanced Token Info order form, at marketplace.dexscreener.com/product/token-info/order. There is no free upload path and no separate "add a banner" endpoint. The field order on the live form, top to bottom:

1. Chain selector, then Token Address. The form validates the address against DexScreener's index before it lets you continue.
2. Description. The help text reads "Plain text only. Emojis and multilines allowed." A separate validator rejects the submission with "URLs are not allowed on description, use the links section instead."
3. Links. Nine typed slots — Website, Docs, X, Telegram, Discord, TikTok, Instagram, Reddit, Farcaster — plus free-form label/URL pairs for anything else.
4. Images. Icon first, then Header. Both upload immediately and show a preview; both have a clear button.
5. Locked Supply. Optional wallet addresses holding locked supply, plus a supply description, used to correct the market-cap calculation.

DexScreener's product page states most orders are processed within a few minutes but to allow up to 12 hours. Pricing sits on the same page — as of 2026-08-04 the product lists at $299, marked down from a struck-through $499 — and the cost, the review queue and the rejection reasons are covered in depth in the Enhanced Token Info guide. If what you actually want is the blue checkmark rather than the images, that is a different paid layer entirely and the DexScreener verification guide is the right page.

If the form already knows your token, it says so: "This token already contains Enhanced Token Info", and routes you to an update rather than a fresh order.

The prerequisite nobody mentions: the pool

You cannot upload a banner for a token that does not exist on DexScreener, and DexScreener's own documentation is explicit about what puts a token there: "All tokens are listed on DEX Screener automatically as soon as they are added to a liquidity pool and have at least one transaction."

That is the whole gate. No pool, no pair page, no address for the form to validate, no image fields. The sequence that works:

1. Mint the token with correct metadata. Name, symbol and image set at creation, so DexScreener has something to render even before you pay for anything. Start here if the token does not exist yet.
2. Open a pool and seed it. A Raydium pool costs roughly 0.4 SOL of non-refundable rent for its own program accounts, on top of whatever liquidity you deposit — the pool tool handles it, and the Raydium walkthrough explains the mechanics. Model the whole budget in the cost calculator first if you have not.
3. Wait for the pair page. Listing timelines covers what "automatic" means in practice.
4. Then buy Enhanced Token Info and upload the assets.

Token creation itself runs about 0.21-0.22 SOL all-in on alchemii for a standard launch — a 0.2 SOL flat service fee that already includes a locked revoke-freeze, plus roughly 0.01 SOL of network fees and account rent. Revoking mint authority as well takes it to about 0.32 SOL. The protocol floor underneath every tool on Solana, no-code or CLI, is about 0.0191 SOL.

Doing the assets in the wrong order is the classic own-goal: people design a beautiful 1500x500 header on launch morning, then discover the upload form will not accept their token for another two hours because the pool is not seeded. Design it early, ship it after.

What gets a submission rejected

DexScreener's refund policy is narrower than most people assume. Refunds are issued only if the order is delayed by DexScreener's own technical issues, if you were charged twice, or if DexScreener cancels the order — and only if you ask within 14 days. Being unhappy with a completed order is on the explicit exclusion list. So the asset-side failure modes are worth getting right the first time. From the form's own field help text and its file inputs:

Cause	What happens
Header narrower than 600px	Below the form's stated minimum — expect the upload to fail
Icon narrower than 100px	Below the form's stated minimum — expect the upload to fail
Any file over 4.5MB	Over the form's stated cap — expect the upload to fail
Wrong format (svg, avif, bmp, tiff)	The file picker will not offer it — this one is enforced in the browser, by the accept attribute
URL inside the description	"URLs are not allowed on description, use the links section instead."
Token address with no indexed pair	The form never enables the image fields

The ones that pass validation but still look wrong are the ones to worry about: an off-ratio header that gets cropped through your logotype, and an under-1500px upload that is soft on every desktop surface forever. Neither produces an error. Both are permanent until you pay to update.

After the assets are live, the rest of the trust surface is a separate job — verifying the token's on-chain state, running the audit checker against the mint, publishing LP burn proof, and getting the same metadata accepted by Phantom and CoinGecko. A polished header on a token with live mint authority fools nobody who checks, and the people who move size always check. The security overview is the short version of what they are looking at.

Limitations

Read these before you treat this page as gospel.

• DexScreener does not publish an image spec. Nothing here comes from official documentation, because there is no official documentation for it. Every dimension, minimum and file-size cap was read off the live Enhanced Token Info order form's own field help text on 2026-08-04. DexScreener can change any of it without notice and without a changelog. Re-check the form before a launch you care about.
• The CDN allowlists were probed, not documented. The four header sizes and four icon sizes were established by requesting sizes and recording 200s and 422s against live assets. They are what the CDN served today. They are not a contract.
• The crop anchor is undetermined. fit=crop is the CDN's stated behaviour and off-ratio requests do return exact, unpadded dimensions — but I did not establish whether the crop is centred, top-anchored or content-aware. Keep critical artwork away from all four edges rather than assuming a centre crop.
• The failure modes were read, not triggered. I did not submit an undersized, oversized or off-ratio file to watch it bounce. The only rejection I can prove happens in your browser is the format filter, because the accept attribute is right there in the markup. The width and file-size rules are what the form's own help text states; whether they are enforced at upload, at review, or both is unverified.
• The social preview bytes are PNG, but DexScreener labels them JPEG. All six previews I pulled start with a PNG magic number and measure 1200x630, yet the response arrives with Content-Type: image/jpeg. Treat the format as PNG and the header as noise, but do not build tooling that trusts that content type.
• I did not measure the rendered display box on the pair page. The ladder tells you what the CDN serves, not the CSS dimensions of the element on any given breakpoint. "Safe zone" advice on this page is derived from the aspect ratio, not from measuring the live page.
• The GIF findings are a 28-header sample. Three animated headers is enough to prove GIF support survives the pipeline. It is not enough to characterise how DexScreener re-encodes animation in general, and the non-monotonic byte sizes suggest the encoder behaves differently per render size in ways I did not fully map.
• Pricing, review times and rejection handling are out of scope. Those belong to the deep dive on buying Enhanced Token Info and the verification guide. The single price quoted above is a dated observation, not a maintained figure.
• Solana-specific framing, chain-agnostic specs. The image specs are identical for every chain DexScreener indexes; the pool prerequisite and the cost figures are Solana. Ethereum, Base and BSC deployers get the same 3:1 header and a completely different fee reality.

FAQ

What is the correct DexScreener banner size?

DexScreener calls it the Header, and it takes a 3:1 rectangle. The upload form gives 600x200px and 1500x500px as its two worked examples, sets a minimum image width of 600px, accepts png, jpg, webp and gif, and caps the file at 4.5MB. Upload 1500x500 — that is the largest size DexScreener's image CDN will ever serve, and asking it for one pixel wider returns an HTTP 422 error. Checked on the live form on 2026-08-04.

What size should a DexScreener token logo be?

The Header's companion field is called Icon, and it takes a 1:1 square. The form's worked examples are 100x100px and 500x500px, the minimum image width is 100px, accepted formats are png, jpg, webp and gif, and the cap is 4.5MB. Upload 500x500. DexScreener's CDN renders icons at 64, 128, 160 and 256 pixels square depending on surface, so anything above 512 is wasted bytes.

Does DexScreener support animated GIF banners?

Yes. The Header field's accept list includes image/gif, and animation survives the pipeline. In a survey of 28 boosted-token headers on 2026-08-04, three were served as image/gif with 49 to 59 frames intact. The practical constraint is weight rather than support: the upload cap is 4.5MB, and one 59-frame animated header came back at 2.7MB served at 1500x500 and 4.1MB served at 900x300 — the same order of magnitude as the cap, with no headroom for a longer or more detailed loop.

Why does my DexScreener banner look blurry?

Almost always because the file you uploaded was narrower than 1500px. DexScreener's CDN downscales but does not upscale, so a 900px-wide upload stays 900px wide on a surface asking for 1500. In a 12-token sample taken on 2026-08-04, four tokens topped out at 1023, 1014, 900 and 1281 pixels wide — a third of the sample shipped a header that cannot fill DexScreener's largest render.

Where do I upload a banner on DexScreener?

The Header and Icon fields live inside the Enhanced Token Info order form at marketplace.dexscreener.com/product/token-info/order. There is no free banner upload — the image slots exist only inside that paid product. The form opens with a chain selector and a token address, so your token has to already be indexed, which means it needs a live liquidity pool with at least one trade before the fields become usable.

What are the DexScreener social preview dimensions?

1200x630 pixels, served as a PNG from cdn.dexscreener.com/token-images/og/. You cannot upload it. DexScreener composes it automatically from your icon, header and live pair data, which is why the preview that appears when someone pastes your pair link into X or Telegram changes as your chart changes. Verified across six token profiles on 2026-08-04, all six exactly 1200x630.

Is the DexScreener trending bar ad a wide banner?

No, and this is the most common mix-up. Trending Bar Advertising and Token Advertising both take a 1:1 square image, not a 3:1 rectangle — same 100px minimum width and 4.5MB cap as the icon, but png, jpg and webp only, with no gif. The only genuinely wide, banner-shaped asset DexScreener accepts is the Enhanced Token Info Header at 3:1.

References

1. DEX Screener Marketplace — Enhanced Token Info product and order form — source of every Header and Icon dimension, minimum width, format list and file-size cap on this page
2. DEX Screener Marketplace — Trending Bar Advertising — the square ad creative, package durations and rotation behaviour
3. DEX Screener Docs — Token Listing — the "liquidity pool plus at least one transaction" indexing rule quoted above
4. DEX Screener Docs — API Reference — the TokenProfile schema with its icon, header and links fields
5. DEX Screener API — latest token profiles endpoint — the live sample used for the render-ladder and under-sizing measurements
6. Metaplex — Token Metadata standard — the on-chain source DexScreener falls back to when Enhanced Token Info is absent
7. SPL Token Program reference — mint, authority and supply mechanics behind the locked-supply fields
8. Solana Docs — Accounts and rent — the account model behind the rent figures quoted for mint, ATA and metadata accounts
9. Raydium Docs — CPMM (Standard AMM) overview — the pool type most new Solana tokens list with, and the one DexScreener indexes first
10. Pinata — IPFS hosting and dedicated gateways — where the on-chain metadata image should live so it resolves at index time
11. Phantom Learn — wallet-side token display, a separate indexer reading the same metadata
12. BONK on Solscan — reference mint for checking metadata state against a token with a complete DexScreener profile

---

Gary Zhao is the founder of Alchemii, a Solana token creation and liquidity tooling platform. He has launched memecoins and utility tokens on Solana mainnet since 2022, and spends most of his week inside the indexers that decide how a new token looks to a trader. Every number on this page was measured against DexScreener's live upload form and image CDN on 2026-08-04 rather than copied from another blog, and the Limitations section above is an honest list of what those measurements do not establish. If DexScreener changes a spec and this page goes stale, tell us — a spec sheet with one wrong number is worse than no spec sheet.

Ready to get to the point where the upload form will actually accept your token? Mint it with the metadata set correctly the first time, then open and seed a Raydium pool. Once the pair page exists, the banner is the easy part. Watching a format that's already working? The trending board is the fastest way to see what current memecoin art direction actually looks like at 3:1.