LoRA Model Compatibility Guide
A LoRA is compatible with the model architecture it was trained against, not every checkpoint that happens to accept a .safetensors file. An SD 1.5 LoRA belongs with SD 1.5. An SDXL LoRA belongs with SDXL-family checkpoints. Pony and Illustrious are SDXL-derived ecosystems, but their prompting conventions and training distributions make same-family compatibility less predictable. FLUX uses a different model architecture and needs FLUX-specific adapters.
The filename isn't proof. Embedded metadata, tensor names, a marketplace page, and a file hash can each supply useful evidence, but none replaces a controlled test with the intended base model. This guide gives you a repeatable compatibility check before you waste time debugging weak output, loader errors, or a LoRA that appears to do nothing. It also explains the hardest cases: mislabeled files, missing metadata, SDXL derivatives, and adapters that load successfully but produce poor results.
The Quick Answer
Key Takeaway — July 2026: Match the LoRA's architecture first, then its intended base checkpoint or ecosystem. SD 1.5, SDXL, and FLUX adapters aren't interchangeable. Pony and Illustrious sit in the broader SDXL family, yet a LoRA trained for one may perform badly on another even when the file loads without an error.
A successful load only proves that the frontend could apply the adapter weights. It doesn't prove that the LoRA recognizes its trigger, preserves the subject, or behaves at the creator's recommended strength.
Use four signals, in this order:
- Source record: Check the model version page or repository card for the declared base model.
- File hash: Match the file's SHA-256 hash to the published version when a trusted host provides one.
- Embedded evidence: Inspect metadata and tensor-key patterns for architecture and training clues.
- Controlled output: Test one prompt, one seed, and several nearby strengths against the intended checkpoint.
Compatibility Matrix
| LoRA family | Use with | Don't use with | Main compatibility risk |
|---|---|---|---|
| SD 1.5 | SD 1.5 checkpoints and related SD 1.x fine-tunes | SDXL, Pony, Illustrious, FLUX | Old or sparse metadata can hide the original training base |
| SDXL | Base SDXL and compatible SDXL fine-tunes | SD 1.5, FLUX | Fine-tune style and text-encoder differences can weaken results |
| Pony | Pony-family SDXL checkpoints, preferably the named training base | Plain SDXL, Illustrious, SD 1.5, FLUX | Score tags, source tags, and dataset conventions matter |
| Illustrious | Illustrious-family SDXL checkpoints, preferably the named training base | Plain SDXL, Pony, SD 1.5, FLUX | Anime tagging and checkpoint lineage affect trigger behavior |
| FLUX | The FLUX variant or compatible FLUX pipeline named by the creator | SD 1.5, SDXL, Pony, Illustrious | Transformer targets and text-encoder components differ from SD models |
"SDXL-derived" doesn't mean "universally compatible." Pony and Illustrious LoRAs can expose SDXL-shaped weights, so a generic loader may accept them. Their concepts may still be tied to a particular checkpoint lineage, caption style, or tag vocabulary.
What Each Model Family Means
SD 1.5
SD 1.5 LoRAs target the SD 1.x UNet and, in some cases, its CLIP text encoder. They have the broadest legacy tool support, but age creates a practical problem: many files were released before creators consistently embedded complete metadata.
Don't infer SD 1.5 from a small file size or a name containing v1. Check the host record and tensor keys. If both are missing, test only in a disposable workflow and keep the weight low enough to spot corruption before it dominates the image.
SDXL
SDXL has a different network structure and two text encoders. Hugging Face Diffusers exposes an SDXL-specific LoRA loader, which is a clear technical boundary between SDXL and SD 1.5 adapters.
An SDXL LoRA usually transfers across related SDXL checkpoints better than it transfers into a different ecosystem. "Usually" matters: a style LoRA trained on base SDXL can behave differently on a heavily tuned anime checkpoint because the checkpoint has already shifted the visual distribution.
Pony
Pony is an SDXL-derived ecosystem with its own prompting and tagging habits. Many Pony LoRAs depend on score tags, source tags, character tags, or a specific Pony checkpoint generation.
Treat "Pony" as more specific than "SDXL." Start with the exact base named on the model page. If the creator only says SDXL, inspect examples and training tags before assuming plain SDXL was intended.
Illustrious
Illustrious is also an SDXL-derived ecosystem, commonly used for anime and illustration workflows. Its LoRAs may technically load in other SDXL pipelines while losing character accuracy, style strength, or prompt response.
Don't treat Illustrious and Pony as aliases. Use the declared Illustrious base first. Cross-testing can be useful after you establish a known-good result, but it shouldn't be your first compatibility check.
FLUX
FLUX uses transformer-based denoising components rather than the SD 1.5 or SDXL UNet arrangement. Diffusers provides a separate FLUX LoRA loader, so an SD-family adapter isn't a drop-in substitute.
FLUX adapters can also depend on which components were trained and which FLUX pipeline the creator used. Follow the repository or model-version instructions instead of assuming every adapter labeled "FLUX" fits every FLUX-derived setup.
How to Check a LoRA Before Loading It
1. Preserve the original filename and source
Save the model-page or repository URL beside the file. Renaming character_v3.safetensors to something tidy can remove the only human-readable clue when embedded metadata is empty.
Prefer a version-specific page over a creator profile or search result. A single model listing can contain several versions trained on different bases.
2. Verify the exact version and hash
Compare the local SHA-256 hash with the host's file record when available. A matching hash ties your file to that exact published asset; a matching model name does not.
Civitai's API exposes model-version fields such as baseModel, file hashes, and an AIR identifier. Those records are stronger evidence than tags copied into a filename.
3. Inspect safetensors metadata
Safetensors can contain a __metadata__ string-to-string map. Training tools often save ss_* fields, adapter configuration, model names, dataset information, or trigger words there.
Metadata helps answer:
- What trainer wrote the file? This tells you how to interpret familiar field names.
- What base was recorded? A model name or hash can narrow the family.
- Which modules were targeted? UNet, transformer, and text-encoder keys affect loader choice.
- What trigger words were captured? These can confirm that you found the right release.
4. Inspect tensor names and shapes
Tensor-key patterns can distinguish broad architectures when descriptive metadata is absent. This is useful evidence, not a perfect family detector.
A derivative may share SDXL tensor structure without declaring whether it was trained for base SDXL, Pony, or Illustrious. Tensor inspection can say "SDXL-shaped" while leaving the ecosystem unresolved.
5. Build a controlled test
Load the intended base checkpoint with no other LoRAs, embeddings, ControlNets, or prompt-expansion tools. Generate a baseline image, then enable only the LoRA.
Keep these values fixed:
- Seed: Use the same seed for every comparison.
- Prompt: Include the documented trigger exactly as written.
- Sampler and scheduler: Start with the creator's example when it exists.
- Resolution: Use the base model's normal working resolution or the creator's example.
- Strength: Test a small range around the documented recommendation instead of jumping to an extreme.
6. Record the known-good combination
Store the LoRA hash, checkpoint name and hash, trigger, strength, frontend, and workflow version. This turns a one-off success into a reproducible setup.
If you want a current generation product with a pre-configured local interface, review LocalForge AI as one option; LoRA training and compatibility validation still require you to choose the right base and verify the adapter.
What File Metadata Cannot Prove
Embedded metadata is optional and creator-supplied. It can be missing, stale, incomplete, or copied from an earlier training run.
Safetensors also limits free-form metadata to string keys and string values. Tools can serialize JSON inside a string, but the format doesn't validate the truth of a base-model claim or require a common schema.
Metadata cannot prove:
- Exact checkpoint lineage: A friendly model name may not identify the precise file used for training.
- Good cross-checkpoint behavior: Architectural compatibility doesn't guarantee visual compatibility.
- Trigger correctness: A listed trigger may be outdated or optional.
- License rights: Technical metadata isn't a license grant. Read the source license and usage terms.
- File identity by itself: A hash verifies identity only when you compare it with a trusted published record.
Newer proposals such as sd.artifact.v1 can make files more self-describing, but support isn't universal. Keep the source record and hash even when a viewer displays rich metadata.
Common Failure Modes
The loader reports missing or unexpected keys. The adapter probably targets another architecture, component layout, or naming convention. Recheck the declared family before changing random node settings.
The file loads but has no visible effect. Confirm the trigger, increase strength gradually, and test the intended checkpoint. Missing text-encoder weights or a mismatched tagging style can make the concept hard to invoke.
The result collapses at moderate strength. You may have a checkpoint mismatch, an overtrained adapter, or conflicting LoRAs. Test the adapter alone on the named base.
A Pony LoRA looks weak on plain SDXL. That's expected when the concept depends on Pony's training distribution and tag conventions. Move back to the named Pony base before editing the prompt.
An Illustrious LoRA loads in Pony but changes the wrong traits. Loading isn't proof of ecosystem compatibility. Use its Illustrious base and documented tags.
A FLUX LoRA is rejected by an SDXL loader. That's an architecture mismatch, not a corrupt file. Use a FLUX-capable pipeline and the correct adapter loader.
Bottom Line
Architecture is the hard boundary: SD 1.5, SDXL, and FLUX need their own LoRAs. Pony and Illustrious require a second compatibility check inside the SDXL family because ecosystem and checkpoint lineage affect real output.
Trust a version-specific source record and matching hash first. Use metadata and tensor keys as supporting evidence. Finish with a controlled generation test, because only output can confirm that a technically loadable LoRA is useful in your workflow.