ImgBB API # The ImgBB API, end to end. ImgBB's API is one endpoint and three parameters, and for a quick anonymous upload that minimalism is the point — you can be hosting an image in about a minute. It's worth knowing exactly where that design stops being enough before you build on it. Here's the whole surface, and the one operation it doesn't cover. ## The parameters Parameter Required Accepts Notes key Required Your API key Passed as a query-string parameter, not a header. image Required Binary file, base64 data, or an image URL Up to 32 MB. The same parameter takes all three forms. name Optional A filename Auto-detected when you POST as multipart/form-data. expiration Optional 60 – 15552000 (seconds) Auto-deletes after the interval. Max is 180 days. Omit it and the upload has no expiry set. Read from the official docs at [api.imgbb.com](https://api.imgbb.com/) on 17 September 2026. ImgBB can change the API at any time — check their page before you build against it. This page is published by PixelVault, which competes with ImgBB; we've tried to describe the API as it is and to be explicit about where ImgBB is the better pick. ## Uploading One endpoint — `https://api.imgbb.com/1/upload` — taking POST or GET. The `image` parameter is refreshingly flexible: the same field accepts a binary file, a base64 string, or a remote URL, so you don't need to learn three call shapes. \# Upload a local file to ImgBB curl -X POST \\   -F "image=@screenshot.png" \\   "https://api.imgbb.com/1/upload?key=YOUR\_API\_KEY" \# Same endpoint, but from a remote URL curl -X POST \\   -F "image=https://example.com/photo.jpg" \\   "https://api.imgbb.com/1/upload?key=YOUR\_API\_KEY" \# Auto-delete after 10 minutes (600 seconds) curl -X POST \\   -F "image=@screenshot.png" \\   "https://api.imgbb.com/1/upload?key=YOUR\_API\_KEY&expiration=600" ## What comes back A JSON envelope with `success`, `status`, and a `data` object holding the image metadata, pre-generated `thumb` and `medium` variants, and a `delete_url`. {   "data": {     "id": "2ndCYJK",     "url": "https://i.ibb.co/w04Prt6/carrot.jpg",     "display\_url": "https://i.ibb.co/98W13PY/carrot.jpg",     "width": 1280,     "height": 720,     "size": 168906,     "thumb": { /\* … \*/ },     "medium": { /\* … \*/ },     "delete\_url": "https://ibb.co/2ndCYJK/670e..."   },   "success": true,   "status": 200 } ## The part that catches people out: deletion The `delete_url` in that response looks like an API affordance. It isn't. It's a web page — `https://ibb.co/[ID]/[deletekey]` — that a human opens in a browser and confirms. There is no documented DELETE endpoint. For a one-off share that's fine. For anything programmatic it's a real constraint: your service can upload an image but cannot take it back down. If a user deletes their account, or you upload something by mistake, or a customer asks you to remove an image, the only path is to persist every `delete_url` somewhere and have a person visit each one. Worth knowing before it's load-bearing. ## Expiry is set once, at upload The `expiration` parameter takes 60 to 15,552,000 seconds — one minute to 180 days — and the image self-deletes at the end of it. It's a genuinely useful escape hatch given there's no delete API, and it's the right tool for ephemeral previews. The catch is that it's decided at upload time: nothing in the docs lets you extend, shorten or cancel it afterwards, so you have to know an image's lifetime before you've uploaded it. ## A note on the key The key travels in the query string. That's the documented design, and it works — but query strings are the part of a URL most likely to be written down by something you don't control: server access logs, proxy logs, browser history, a `Referer` header. If you use ImgBB from a backend, keep the key server-side and treat log redaction as your problem to solve rather than assuming it's handled. ## When ImgBB is the right call Genuinely: when you want an image on the internet with minimal ceremony. No account modelling, no project structure, no SDK — sign up, grab a key, POST a file. For a personal script, a hobby project, a forum image, or a quick prototype, the simplicity is a feature and the missing pieces never come up. ## When you've outgrown it The line is roughly where other people's images start passing through your code. At that point you tend to need things the upload-only design doesn't cover: deleting an image from code, keeping one customer's uploads separable from another's, and an auth model where the credential isn't in the URL. Here's how the two APIs line up. We build PixelVault, so read the right-hand column with that in mind — the rows where ImgBB wins are in there too. ImgBB PixelVault Upload with no account at all No — a key is required Yes — keyless upload, kept ~30 days Where the credential travels key in the query string Bearer token in an Authorization header Delete from code No — delete\_url is a web page Yes — DELETE /v1/images/:id Organising images Flat Folders, plus per-project keys Private images No Private visibility + signed URLs Upload from a remote URL Yes Yes (key required) Base64 input Yes, on the upload endpoint On the batch endpoint Max file size 32 MB 5 MB Longest expiry you can set 180 days 30 days Batch upload Not documented Yes MCP server for agents No Yes Free tier Free — no published limits 200 MB storage, 500 uploads/month ## Where ImgBB is still ahead Two rows above are worth calling out because they go the other way. ImgBB accepts **32 MB** per image against PixelVault's **5 MB** — if you're hosting high-resolution photography or large scans, that difference decides it, and no amount of API surface makes up for a file you can't upload. ImgBB also lets you set an expiry up to **180 days**, where PixelVault's ephemeral uploads cap at 30. And base64 works on ImgBB's single upload endpoint, while on PixelVault it's the batch endpoint that takes base64 items. ## Hosting an image without an account at all The one row with no ImgBB equivalent: PixelVault takes an upload with _no API key and no signup_. That matters most for coding agents and scripts, where the account-creation step is the part that can't be automated — an agent can go from "I have a PNG" to "I have a URL" in one call, with nothing to provision first. \# No key, no account. Just POST the file. curl -X POST \\   -F "file=@diagram.png" \\   "https://api.pixelvault.dev/v1/images" The honest catch: keyless uploads are **kept about 30 days**, not forever. They live under a shared anonymous prefix and are cleared by a storage lifecycle rule. It's the right tool for a CI screenshot, a scratch diagram, or an agent sharing a render mid-conversation — not for a README image that has to survive. For permanence you register (which the API does support programmatically), verify an email, and upload with a key. ## What it costs ImgBB's API is free and has no published paid tier — which also means no published rate limit or uptime commitment to hold it to. PixelVault's free tier is 200 MB of storage and 500 uploads a month with no credit card; paid plans are on the way but aren't purchasable yet, so today the free tier is the offer. Full detail on [the pricing page](/pricing), the equivalent calls in the [API docs](/docs), and a broader feature comparison on [the ImgBB alternative page](/alternatives/imgbb). ## ImgBB API FAQ How do I get an ImgBB API key? Create a free ImgBB account, then open the API page at api.imgbb.com and request a key. It is free and there is no paid API tier to upgrade to. The key is then passed on every request as a query-string parameter named key. Is the ImgBB API free? Yes. ImgBB does not publish a paid API plan, so the key you get is the only key there is. The trade-off is that there is no published rate limit or uptime commitment either — nothing in the public docs tells you how many requests per minute you may make, or what happens when you exceed it. What is the ImgBB API endpoint? A single endpoint: https://api.imgbb.com/1/upload. It accepts POST (preferred) or GET. There is no separate endpoint for listing, fetching or deleting images — upload is the whole API surface. How do I delete an image from the ImgBB API? You cannot delete programmatically. Each upload response includes a delete\_url of the form https://ibb.co/\[ID\]/\[deletekey\], and that URL is a web page a person opens in a browser. There is no DELETE endpoint documented, so a script cannot revoke an image it uploaded — it can only store the delete\_url and hope someone visits it later. How long does ImgBB keep images? Indefinitely, unless you set the expiration parameter at upload time. That parameter accepts 60 to 15552000 seconds, so the longest expiry you can set is 180 days. It is set once, at upload — there is no documented way to change or extend it afterwards. What is ImgBB's maximum upload size? 32 MB per image, for all three input forms — binary file, base64 data, and remote URL. Can the ImgBB API upload from a URL or base64? Yes, and this is one of its genuinely nice touches: the single image parameter accepts a binary file, a base64 string, or a remote image URL. You do not need a different call or a different endpoint for each. ## An API that can delete what it uploads API-key auth in a header, per-project organisation, and list/fetch/delete from code. Free to start — no credit card. [Read the API docs](/docs)