Qwen-Image-Edit: The Edit Line, Checkpoint by Checkpoint

This is the reference page for the Qwen-Image-Edit line — the instruction-following image editor, not the text-to-image generator it was built alongside. The line has exactly three published checkpoints: Qwen-Image-Edit, released 17 August 2025 and built on the 20B Qwen-Image; Qwen-Image-Edit-2509, the monthly iteration published 22 September 2025; and Qwen-Image-Edit-2511, published 17 December 2025 as an enhanced version of 2509. Everything on this page is centred on the most recent of those three, and it says which checkpoint each statement is about, every time. There is one more thing to name up front because it is the answer to the question most people are actually asking: Qwen-Image-2.1 is a unified text-to-image and image-editing model with a 7B visual generation component, and Qwen-Image-2.1-Turbo is the same model as an 8-step accelerated checkpoint. Neither of them is an entry in the edit line, and that distinction is the whole reason this page exists.

Qwen-Image versus Qwen-Image-Edit

If you searched for the difference between Qwen-Image and Qwen-Image-Edit you were asking which of two things you have in front of you. The answer is clean and it is worth stating flatly, because the two are not interchangeable and the file names do not tell you apart.

• Qwen-Image — a text-to-image model. You hand it words, it hands you a picture. It is the model Qwen-Image-Edit was built on top of. The original edit checkpoint's own card describes it as "the image editing version of Qwen-Image," built upon the 20B Qwen-Image model, which is how it inherits Qwen-Image's text rendering.

• Qwen-Image-Edit — an image-to-image model. You hand it a picture plus words, and it hands you a modified version of that picture. The first checkpoint's card files it under pipeline_tag: image-to-image. You cannot ask it for a picture out of nothing; the source image is not optional.

• The mechanism that makes editing different — where the generator has one path in (text), the editor has three. The original checkpoint's card describes feeding the input image simultaneously into Qwen2.5-VL for visual semantic control and into the VAE encoder for visual appearance control. That second path is what a text-to-image model structurally does not have: the editor is not being told about your image in words, it is looking at your image's latents.

• Where the two lines converge again — Qwen-Image-2.1 is described on its own card as "a unified text-to-image generation and image editing model." That is a different architecture of answer to the same question: rather than an edit checkpoint bolted onto a generator, one model does both. Its editing example passes an image= argument to a pipeline you also use for text-to-image. If you are trying to work out which family you have, the quickest tell is the checkpoint name: a name in the Qwen-Image-Edit… series is the edit line, and a name in the Qwen-Image-2.1… series is the unified model.

Nothing here is a recommendation between them. They are different answers to different problems, and the rest of this page is about the first one.

Instruction adherence: what it changes, and what it leaves alone

This is the question the search demand says people are actually typing, and it deserves a direct answer rather than a feature list. The honest answer has two halves, and only one of them is comfortable.

Start with the half that is built into the model's design, because it explains most of the "it changed more than I asked" reports. The original Qwen-Image-Edit card draws a line between two modes, and only one of them promises that anything will be preserved.

• Appearance editing — low-level visual work such as adding, removing, or modifying specific elements. The card's own wording is that this requires "all other regions of the image to remain completely unchanged." This is the mode that matches what most people mean by editing.

• Semantic editing — high-level work such as IP creation, object rotation, and style transfer. Here the card says the opposite: it "allows overall pixel changes while maintaining semantic consistency." The vendor's own worked example of this is a capybara mascot redrawn across many styles, where the card notes that "most pixels in the edited image differ from those in the input image" while character consistency is preserved.

That second mode is not a bug, and the card does not present it as one. But it is the reason a request like "make this look like a Ghibli film" can legitimately come back as an image that shares almost no pixels with your source. If you wanted only the sky changed, you were not asking for semantic editing. Read these as vendor-reported descriptions of intended behaviour, not as measurements — the card states them as design, and no party has published a rate at which each mode holds its promise.

Now the half that is less comfortable. The line's own project acknowledged instruction-following problems early, in its own notes. The Qwen-Image repository's notes for the original checkpoint, dated 19 August 2025, flag "performance misalignments" in that first release and call out identity preservation and instruction following specifically, directing users to an updated Diffusers build. That is a vendor-reported admission about a vendor's own model, which is about as direct as evidence on instruction adherence gets — and it is about the August 2025 checkpoint, not about 2511.

The vendor's own worked example of a hard case is more instructive than any claim. In the chained-editing walkthrough on the original card, a calligraphy artwork generated by Qwen-Image contains character errors, and the editor is asked to fix 稽 inside a drawn red box and 亭 inside a blue one. The card reports that 稽 — an obscure character — is not corrected correctly in a single step: the lower-right component should be 旨 and comes back as 日. Only after drawing a further red box tightly around the 日 region does the model produce the correct component. Two things follow from that, and the vendor states both: bounding boxes on the source image are a real control mechanism, and one bounded correction step is not always enough. That is a vendor-reported failure and a vendor-reported recovery on a vendor-chosen example, which is exactly the shape such evidence should take.

Categories the cards document as working, each as a vendor claim rather than a measured result:

• Element-level edits with preservation — adding a signboard to a scene (the original card notes the model also generated a matching reflection), removing fine strands of hair and small objects, recolouring a single letter in an image.

• Bilingual text editing — adding, deleting and modifying Chinese and English text in an image while preserving the original font, size and style. The 2509 card extends this to editing font type, colour and material, and the original card shows Chinese poster editing down to small and intricate text.

• Identity and character consistency — 2509's card reports improved facial identity preservation supporting pose transformations and portrait styles; 2511's card reports further gains on multi-person group photos and on fusing two separate person images into one coherent group shot.

• Novel view synthesis and object rotation — the original card shows 90-degree and full 180-degree object rotation, explicitly placing this in semantic editing where whole-frame pixel change is expected.

• Product work — 2509's card reports generating product posters from plain-background product images, plus logo generation. 2511's card adds batch industrial product design and material replacement for industrial components.

• ControlNet-style conditioning — 2509's card reports native support for depth, edge and keypoint maps and sketches, including using a keypoint map to change a person's pose.

• Guide taking — 2509's card reports that multi-image editing works through image concatenation across "person + person," "person + product" and "person + scene," and states that optimal performance is currently achieved with 1 to 3 input images. That upper bound is vendor guidance, not a hard limit, and it is stated for 2509.

• Newer capabilities in 2511 — the card lists mitigating image drift, integrating selected popular community LoRAs directly into the base model, enhanced industrial design generation, and strengthened geometric reasoning, with an example of generating auxiliary construction lines for design annotation.

The checkpoints, the names, and the turbo path

This is where a lot of search traffic goes wrong, so it is worth being exact. The model organisation's own listing on Hugging Face contains three, and only three, repositories in the edit line. That is a negative finding established by direct probe: the three real repositories resolve, and a set of plausible-looking names in the same family — including Qwen/Qwen-Image-Edit-2.1, -3.0, -3, -2512, -2601, -Plus, -Max, and both Qwen/Qwen-Image-2.1-Edit and Qwen/Qwen-Image-Max-2512 — do not resolve under identical conditions. Whatever those names refer to, they are not published checkpoints from the model's own organisation, and this page will not guess what they are.

The three that exist:

• Qwen-Image-Edit — the original, 17 August 2025, Apache-2.0, filed as image-to-image. Loaded with QwenImageEditPipeline. Its own quick start uses true_cfg_scale=4.0, negative_prompt=" " and num_inference_steps=50.

• Qwen-Image-Edit-2509 — 22 September 2025, Apache-2.0, described on its card as "the monthly iteration of Qwen-Image-Edit." Loaded with QwenImageEditPlusPipeline; its quick start uses true_cfg_scale=4.0, num_inference_steps=40 and guidance_scale=1.0. This is the checkpoint that added multi-image input, the stronger consistency work and native ControlNet support.

• Qwen-Image-Edit-2511 — 17 December 2025, Apache-2.0, described on its card as "an enhanced version over Qwen-Image-Edit-2509, featuring multiple improvements—including notably better consistency." It also loads with QwenImageEditPlusPipeline, at the same sampling settings as 2509. If you have no other constraint, this is the newest checkpoint in the edit line.

Which one the reader likely has depends on where they met it. Anyone on a hosted image-editing feature is most likely on 2511 or 2509. Anyone who pulled a checkpoint a year ago and has not touched it is most likely on the original, and the differences that matter to them are the consistency and multi-image work added in 2509 rather than a change in how editing works.

Now the turbo question, stated precisely because the name invites a wrong assumption. Qwen-Image-2.1-Turbo is not a turbo edit checkpoint. Its card describes it as "an accelerated checkpoint of Qwen-Image-2.1 for text-to-image generation and image editing with 8 denoising steps," using the same 7B visual generation architecture and loading directly with QwenImage21Pipeline. So the accelerated path for editing is the accelerated path for the unified model, and it inherits that model's editing behaviour rather than the edit line's.

What turbo changes, concretely:

• Step count — 8 denoising steps, against 40 in the unified model's quick start and 40 or 50 in the edit line's.

• Guidance — generation uses CFG=1 by default, and prefix KV caching reuses the text and reference-image context across denoising steps. That reuse is where a good part of the speedup comes from, and the card's editing example passes use_kv_cache=True explicitly.

• The schedule is saved with the checkpoint — the card states that the recommended 8-step sampling schedule is saved with the checkpoint and loaded automatically, and that setting num_inference_steps alone does not override it. If you set the step count and see no change, that is why. An explicit call-time sigmas argument does override the saved schedule, and the card adds that other schedules have not been evaluated for this checkpoint.

• Fidelity — the card does not make a fidelity claim for the turbo checkpoint against the unified model, and no independent measurement isolating turbo's editing fidelity is available to cite. Anyone telling you the 8-step edit is or is not as faithful as the 40-step edit is going beyond what has been published. What the card does document is the sampling change and the architecture staying the same 7B visual component, which is the reason it is worth testing rather than assuming.

On relative quality, the independent figures are from Artificial Analysis's image-editing board, which is a third-party measurement rather than a vendor claim, and they are worth reading carefully because two of them are not what the names suggest.

• Qwen Image Edit Plus 2511 — 1021 Elo, ±8, 4,478 samples, November 2025, open weights. This is the best-scoring entry in the discrete edit line.

• Qwen Image Edit Plus 2509 — 981 Elo, ±7, 7,390 samples, September 2025, open weights.

• Qwen Image Edit — 918 Elo, ±7, 7,415 samples, August 2025, open weights. That is roughly 103 Elo below 2511 on the same board, which is the size of the gap the consistency work bought.

• Qwen Image Edit Max 2601 — 1000 Elo, ±8, 5,036 samples, dated January 2026 on the board, closed weights. The board lists this entry; no matching repository appears in the model organisation's own listing, so what this checkpoint is cannot be established from primary material. It is reported here as an independent board's row and nothing more.

• Qwen-Image-2.1 — 1074 Elo, ±9, 5,536 samples, open weights, roughly 53 Elo above the best edit checkpoint. Note the board labels this entry's date as September 2026 and adds "No API available." A unified model outscoring the dedicated edit line is the single most useful fact on this page for anyone deciding what to run, and it is an independent measurement, not a vendor claim.

The same page also lists per-1,000-image API costs for several of these entries, and this page deliberately does not carry them: they move, they are board-reported rather than vendor-published, and a reader acting on today's number would want to read it at the source.

What you have to supply

The editor's input requirements are where most failed runs are decided, and the specification is more forgiving than people expect in one direction and less forgiving in another.

• The source image is mandatory and it is the whole input — there is no text-only mode. The original checkpoint's card converts its example to RGB before passing it; the unified model's turbo card loads its example and converts to RGBA, which matters because Qwen-Image-2.1 generates and edits transparent images natively.

• Maskless editing is the documented path in the unified model — the Qwen-Image-2.1 card states that local edits can be specified via circles, painted annotations, or separate masks, and that the model supports up to 10 reference images. The maskless route through circles and painted annotations is the one the card leads with; it is the reason you can mark up a region in an ordinary image editor rather than producing a mask file.

• Masked editing exists as a separate pipeline — a discrete inpaint pipeline exposes mask_image, masked_image_latents and padding_mask_crop alongside a strength parameter that defaults to 0.6. If you have spent time looking for a strength slider on the edit checkpoints and not found one, this is why: the edit line's own pipelines do not take one, and the unified model's editing example passes a prompt and an image with no strength argument at all.

• Source resolution is constrained, and the constraint is arithmetic — both the original and the plus pipeline validate that the height is divisible by twice the VAE scale factor. On the unified model's pipeline the VAE scale factor is 16 and the check warns toward divisibility by 32, with a default output_resolution of 1024. Passing an arbitrary photo size straight through is one of the ordinary ways to get a hard failure rather than a bad edit.

• Native high-resolution presets exist, and they are specific numbers — the unified model and its turbo checkpoint publish the same seven presets: 1:1 at 2048×2048, 4:3 at 2400×1792, 3:4 at 1792×2400, 3:2 at 2528×1696, 2:3 at 1696×2528, 16:9 at 2752×1536 and 9:16 at 1536×2752. The turbo card's text-to-image example uses the 1696×2528 portrait preset and its editing example uses 2048×2048.

• Multi-image input has a documented sweet spot — up to 3 images for 2509, and up to 10 references for the unified model. Exceeding the range the vendor documents is not forbidden, but nothing published describes what happens when you do.

• One more supply requirement that is easy to miss — the unified model's editing path takes a num_inference_steps of 40 in its quick start and its pipeline defaults include use_kv_cache=True and true_cfg_scale=1.0. Reading those defaults before tuning anything will save you a round of confusion about why output changed when you thought you had only changed one thing.

Editing an image you have already edited

This is the least settled area on the page and it is worth separating what is documented from what is not. Two mechanisms are described, and one of them is the vendor's own answer to a failure.

• Chained correction is documented and expected — the calligraphy walkthrough on the original card is a multi-turn loop, not a single pass. The model fails on 稽 in one step, the reader draws a tighter box on the failing component, and the next turn fixes it. The card presents this as the intended way to work rather than as a workaround, and the final result is reached after several successive turns on the same image. If you are editing an already-edited image, you are doing what the vendor documents.

• Image drift is the named risk in the newest checkpoint — 2511's card leads its list of key enhancements with "mitigate image drift," which is the vendor's own term for accumulating unwanted change across turns. The claim is that 2511 reduces it; the card does not quantify by how much, and no independent measurement of drift across a known number of edit turns exists to cite.

• What is not settled — how much quality a third or fifth turn costs, whether drift compounds linearly or plateaus, and whether the turbo checkpoint's 8-step schedule drifts differently from the 40-step path. The vendor publishes no per-turn quality curve for any checkpoint in either line, and the independent boards measure single-pass editing rather than chains. The practical reading is that the vendor's documented workflow is a short bounded chain with a drawn region on each turn, and nothing published supports treating a long chain of unpinned edits as safe.

• Context reuse interacts with chaining — the turbo checkpoint's prefix KV caching reuses text and reference-image context across denoising steps, and the card's editing example switches it on. That is a within-call optimisation, not a across-turns memory; nothing in the card suggests the model retains anything between separate calls. Each turn starts from the image you hand it.

What is not settled

Kept short, because a reference page that hides its edges is worse than one that points at them.

• What "Qwen Image Edit 3" and "Qwen Image Edit 2512" are. Neither name resolves to a repository in the model organisation's own listing, so this page cannot say which generation they name, or whether they name one at all. If a later edit generation is published, it will appear in that listing and this page will be wrong until it is rewritten.

• What Qwen Image Edit Max 2601 is. An independent board carries the row; no matching vendor repository exists. The gap is reported rather than filled.

• Whether turbo costs editing fidelity. No vendor claim, no independent measurement.

• How much drift 2511 actually removes. The vendor claims a reduction and does not quantify it.

• Rates for any of the documented capabilities. Every "works for X" statement on this page is the checkpoint's own card describing intended behaviour on chosen examples. None of it is a measured success rate, and none of it should be read as one.

Your next action is to pick one of the three checkpoints that exist, read that checkpoint's own card before you change anything in its quick start, and hand it a source image whose dimensions satisfy the pipeline's divisibility check. If the reason you came here is that you want to start from an image of your own and keep as much of it as possible rather than change it, that is a related problem with its own walkthrough — the image-to-image page covers starting from your own image and what the absence of a strength control means for it. If instead you want the newer unified model because an independent board puts it above the whole edit line, the accelerated checkpoint is the cheap way to try it before you commit.