The PBIX vs PBIR debate is no longer theoretical — Microsoft is actively rolling out PBIR as the new default Power BI report format, and every developer will be affected. Specifically, Power BI Service already creates all new reports in PBIR format as of early 2026, and Power BI Desktop is scheduled to follow in May 2026. However, the transition also introduces a third format — PBIP — that often gets confused with PBIR, even though the two serve completely different roles.
In this guide, I break down exactly what each format does, how they relate to each other, and what the PBIX vs PBIR transition means for your existing reports and workflows. Additionally, I cover what actually breaks when you switch — something most other guides skip entirely.
- PBIX is the legacy single-file format. It still works today, but Microsoft is phasing it out as the default.
- PBIR is the new report format — human-readable JSON folders instead of a binary blob. It enables Git, CI/CD, and AI-assisted report building.
- PBIP is not a report format. It is the project container that holds PBIR (the report) plus TMDL (the semantic model). Think of PBIP as the folder, PBIR as the report file inside it.
- Power BI Service switched to PBIR as the default in January–February 2026. Desktop follows in May 2026.
- Most existing PBIX users will experience the PBIX vs PBIR transition silently. However, developers using source control, CI/CD, or AI tools have the most to gain from switching now.
PBIX vs PBIR vs PBIP — Quick Definitions
Before comparing PBIX vs PBIR, it helps to understand what each format actually is and why PBIP fits into the picture. Each solves a different problem, and understanding that distinction makes the whole transition make sense.
PBIX — Power BI Desktop File
PBIX (Power BI Desktop file) is the traditional single-file format that has been the standard for Power BI development since the product launched. It stores the data model, Power Query transformations, report visuals, and data connections all in one compressed binary file. Consequently, it is simple to share — one file, one report, done.
However, because PBIX is a binary file, it cannot be meaningfully diffed in Git. Two developers editing the same PBIX simultaneously will always produce a merge conflict with no good resolution. That limitation is the core reason PBIR exists.
PBIR — Power BI Enhanced Report Format
PBIR (Power BI Enhanced Report Format) replaces the binary PBIX report layer with a folder of human-readable JSON files. Specifically, each visual, each page, each bookmark, and each report setting becomes its own JSON file that can be read, edited, and version-controlled like any other code. As a result, PBIR enables proper Git integration, CI/CD pipelines, and — critically — AI-assisted report building directly from the file structure.
For a deeper technical breakdown of what PBIR contains, see my complete guide to the PBIR format.
PBIP — Power BI Project
PBIP (Power BI Project) is not a report format at all — it is a project container. A PBIP project holds two things: the PBIR report folder and the TMDL semantic model definition. In other words, PBIP is the outer wrapper, and PBIR is one of the components inside it.
“PBIP is the container. PBIR is the report. TMDL is the model. These three things together replace the single PBIX file — and once you understand that relationship, the whole PBIX vs PBIR transition makes sense.”
PBIX vs PBIR vs PBIP: Side-by-Side Comparison
The table below compares PBIX (the old format) against PBIR/PBIP (the new format). PBIR and PBIP are not alternatives — PBIR is the report layer, PBIP is the project container that holds it. Together they replace what PBIX did as a single file.
| Feature | PBIX (Old) | PBIR / PBIP (New) |
|---|---|---|
| What it is | Single compressed binary — model, report, and connections in one file | Project folder (PBIP) containing the report as JSON files (PBIR) + model as text (TMDL) |
| Human-readable | ❌ Binary — not readable in any text editor | ✅ Plain JSON + TMDL — open in VS Code or Notepad |
| Git / version control | ❌ Binary diff — merge conflicts are unresolvable | ✅ Line-level diffs — proper branching, PRs, and merging |
| CI/CD pipelines | ❌ No clean automated deployment path | ✅ Fully supported via Azure DevOps or GitHub Actions |
| AI / LLM-buildable | ❌ Binary is opaque — AI cannot read or write it | ✅ JSON is readable and writable by LLMs like Claude |
| Multi-developer work | ❌ One developer at a time — overwrite risk | ✅ Work on separate pages/visuals simultaneously |
| Default (2026) | ❌ No longer default from 2026 | ✅ Service: Jan 2026 · Desktop: May 2026 · GA: Q3 2026 |
| Enable early (Desktop) | — | File → Options → Preview features → “Store reports using enhanced metadata format (PBIR)” |
| Best for | Quick solo reports, simple sharing, legacy workflows | Teams, Git workflows, CI/CD, AI-augmented development |
PBIX — The Format Before PBIR
PBIX has been the standard Power BI file format since 2015. For most individual developers and small teams, it has worked fine — open Desktop, build the report, save the file, publish to the service. That workflow is not going away overnight. However, the PBIX vs PBIR difference becomes most apparent the moment a second developer touches the same file.
What happens to existing PBIX files
According to Microsoft’s official PBIR transition announcement, existing PBIX users will experience the change as completely silent. Specifically, when a PBIX-based report is edited and saved in the Power BI Service after the cutover date, the service automatically upgrades it to use PBIR report metadata behind the scenes. The file extension and the workflow remain the same for the end user. However, the internal structure changes.
That said, there is one important size restriction. As of March 2026, automatic upgrades in the service only apply to reports with fewer than 100 visuals. Reports exceeding that threshold require a manual migration step.
When PBIX Still Makes Sense Over PBIR
For quick, self-contained reports that will never be version-controlled or shared across a development team, PBIX remains a perfectly valid choice. Moreover, if you are working in Power BI Desktop today and not using source control, you will not notice any meaningful difference in your day-to-day workflow until May 2026 when Desktop switches to PBIR as the default format.
PBIR — The New Report Format (And Why It Changes Everything)
PBIR is the most significant change to Power BI’s file architecture since the product launched. Instead of storing report metadata in a compressed binary file, PBIR saves every component of a report as a separate, human-readable JSON file. Furthermore, this structural change has implications far beyond version control.
The PBIR folder structure
A PBIR report folder contains individual files for each report page, each visual configuration, bookmarks, filters, and report-level settings. Specifically, a typical PBIR folder looks like this:
MyReport.Report/ ├── definition/ │ ├── report.json ← Report-level settings │ ├── pages/ │ │ ├── ReportPage1/ │ │ │ ├── page.json ← Page metadata │ │ │ └── visuals/ │ │ │ ├── Visual1/ │ │ │ │ └── visual.json ← Visual config │ │ │ └── Visual2/ │ │ │ └── visual.json │ └── bookmarks/ │ └── bookmark.json └── .platform
In practice, this means every change you make in Desktop results in a meaningful file change that Git can track line-by-line. As a result, pull requests, code reviews, and branching strategies all become viable for Power BI development — something that was essentially impossible with PBIX.
Why PBIR (Not PBIX) Unlocks AI-Assisted Report Building
This is the angle most other PBIR guides miss entirely. Because PBIR is plain JSON, large language models can read, write, and modify report files directly. In my own work, I have been using Claude to generate PBIR report pages from scratch — providing a schema context and getting complete visual configurations back as JSON files that open correctly in Desktop.
“PBIX was a black box. PBIR is a transparent structure. That transparency is what makes AI-assisted Power BI development possible — the AI can read the format, understand it, and write to it.”
For a practical example of this in action, see how I used AI to build a Power BI report from scratch using PBIR. Additionally, the PBIR report builder Claude skill automates exactly this workflow for repeatable report generation.
PBIP — The Project Container (Not a Report Format)
PBIP is the one format that consistently causes confusion — largely because its name suggests it is a report format when it is actually a project structure. Specifically, a PBIP project is a folder that contains two separate components: the PBIR report definition and the TMDL semantic model definition. Together, they make up what a PBIX file previously bundled into one binary.
The PBIP folder structure
MyProject.pbip ← The entry point file
MyProject.SemanticModel/ ← The data model (TMDL)
│ definition/
│ ├── model.tmdl
│ ├── tables/
│ │ ├── Sales.tmdl
│ │ └── Date.tmdl
│ └── relationships.tmdl
MyProject.Report/ ← The report (PBIR)
definition/
├── report.json
└── pages/
└── ...
In other words, PBIP separates the report from the model at the file system level. This separation has a major practical benefit: multiple reports can reference the same semantic model folder, and the model can be version-controlled independently from any individual report. For team workflows, this is a significant advantage over PBIX where model and report are always fused together.
For more on the semantic model side of PBIP, my TMDL guide for Power BI semantic modeling and version control covers the model layer in depth.
PBIP is not a format you can open directly in Power BI Desktop like a PBIX file. You open the .pbip entry-point file, which points Desktop to the folder structure. If you move or rename the subfolder components without updating the .pbip file, Desktop will not be able to locate the project.
How the PBIX vs PBIR Transition Works (2026 Timeline)
The PBIX vs PBIR migration is rolling out in stages, and understanding the timeline is important for planning your team’s move. According to Microsoft’s Power BI January 2026 feature summary, the rollout follows three phases.
Phase 1 — Power BI Service (January–February 2026)
All new reports created in the Power BI Service now use PBIR format by default. The rollout started in January 2026 and completed by the end of February. Additionally, existing service reports are automatically upgraded to PBIR when they are edited and saved — provided they have fewer than 100 visuals.
Phase 2 — Power BI Desktop (May 2026)
Power BI Desktop will switch to PBIR as the default format in the May 2026 release. Notably, this was originally planned for March 2026 but was delayed by Microsoft. For developers working primarily in Desktop, May 2026 is the key date to track. After that release, new files created in Desktop will internally use the PBIR format for report metadata.
Phase 3 — General Availability (Q3 2026)
When PBIR reaches General Availability, it becomes the sole supported report format and Microsoft will automatically convert all remaining reports. Specifically, PBIR-Legacy — the intermediate compatibility layer — will no longer be supported at GA. This is the point of no return for teams that have not yet completed their PBIX vs PBIR migration.
| Date | What Changes | Impact on You |
|---|---|---|
| Jan–Feb 2026 | Power BI Service switches to PBIR default | All new service reports use PBIR. Existing reports upgrade on next edit/save. |
| May 2026 | Power BI Desktop switches to PBIR default | New PBIX files in Desktop use PBIR internally. Workflow feels the same. |
| Q3 2026 | PBIR reaches General Availability | PBIR becomes the only supported format. All remaining reports auto-convert. |
What Breaks in the PBIX vs PBIR Switch — and What Doesn’t
Most guides gloss over this section entirely. In practice, the PBIX vs PBIR migration is mostly smooth — but there are specific scenarios where things go wrong, and it is better to know about them before you hit them on a client project.
What works fine after the switch
In my testing across multiple projects, the following all work without issues after switching to PBIR: standard Power BI visuals, DAX measures and calculated columns, Power Query transformations, report themes (JSON), bookmarks, drill-through pages, row-level security, and deployment pipelines. For the vast majority of reports, the transition is genuinely transparent.
What can break or behave unexpectedly
Based on my experience working with PBIR on live projects, here are the areas that warrant extra caution:
- Large reports (100+ visuals): Automatic upgrades in the service only apply to reports below this threshold. Reports above it require a manual migration path.
- Third-party custom visuals: Most certified AppSource visuals work fine. However, older or uncertified custom visuals may have unexpected behaviour after the format switch. Test before deploying to production.
- Deployment pipeline configurations: If your existing CI/CD setup references PBIX file paths directly, those paths will change in a PBIP project structure. Update pipeline scripts accordingly.
- External tools using the PBIX format directly: Some third-party tools that read PBIX files as binary archives (for model extraction or documentation) may not yet support PBIR. Check your toolchain before migrating.
- Reports created in the service (thin reports): Reports created directly in the Power BI Service — without a corresponding Desktop file — behave differently in the PBIR transition. Always verify service-created reports after the upgrade window.
“The PBIX vs PBIR switch is not risky for most reports — but if you are running a complex enterprise model with hundreds of visuals, custom visuals, or external tooling, test in a development environment before the automatic upgrade reaches your production workspace.”
PBIX vs PBIR: When Should You Make the Switch?
The short answer: switch now if you are doing anything beyond solo report development. Specifically, if any of the following apply to your workflow, PBIR and PBIP will give you immediate, tangible benefits:
- You work in a team where more than one person edits the same report
- You use or want to use Git for version control on Power BI projects
- You are building CI/CD pipelines for report deployment
- You want to use AI tools (like Claude) to build or modify report JSON directly
- You need to document changes to report structure over time
On the other hand, if you are a solo developer building self-contained reports for a single client and not using source control, there is no urgent reason to change your workflow before the May 2026 Desktop update forces the change anyway. In that case, the PBIX vs PBIR transition will simply happen in the background.
For a broader view of how AI tools are changing the Power BI development workflow, see my post on building a Claude skills starter kit for Power BI. Additionally, if you are starting fresh with PBIP projects and want a solid dashboard foundation, the Power BI Background Designer generates production-ready SVG backgrounds designed specifically for PBIP project structures.
FAQ
Ready to work with PBIR?
My complete PBIR guide covers the full format spec, folder structure, and how to set up a PBIP project from scratch.
Read the Full PBIR Guide →About the author: Lukas Reese is a freelance Power BI developer and consultant specialising in advanced data modeling, IBCS-compliant dashboard design, and AI-augmented BI workflows. He works with clients across the US and DACH regions and has been working with PBIP and PBIR since the preview release. | Last updated: March 2026

