Bridge PoB-style sources and PoE2 .build starter files.

What works today

• Paste PoB-style text or links as source input.
• Generate a `.build` starter manifest with source metadata.
• Normalize parseable JSON build content.
• Send the generated output to the checker before importing.

What full conversion requires

True PoB2-to-planner conversion requires stable schemas for passives, items, skills, support gems, ascendancy data, and planner-specific output fields. This v1 keeps the workflow useful while avoiding invented data.

Best use case

Use this converter when you want to archive a build source, create a consistent handoff file, or prepare a starter that can later be enriched as PoE2 community tool schemas mature.

PoB2 conversion boundaries

PoB and PoB2-style build data can contain much more than a visible class and skill list. A useful conversion needs to preserve tree choices, gem setup, item stats, weapon swaps, configuration notes, and sometimes assumptions about buffs or enemy settings. If any of those fields are dropped or guessed, the output may look valid while representing a different build. That is why this page frames conversion as staged work instead of a single magic button.

BuildFileConverter v1 handles the first stage: it captures the source and makes the conversion status explicit. The resulting starter file is useful for documentation, sharing, and later parsing, but it is not marked import-ready. When reliable PoE2 schemas and source decoders are available, the next stage can map the captured source into real planner fields.

How to review a PoB-style source today

• Paste the source into the converter and confirm whether it is treated as a link, text source, or encoded PoB-style block.
• Download the starter manifest and keep it with the original guide notes.
• Do not rename the starter as a finished game import unless your planner supports the fields inside it.
• If you manually create final JSON, run the checker and inspect warnings before import.

This workflow is conservative, but it avoids the worst failure mode: a tool promising a complete conversion while silently losing build-critical details.

Patch-sensitive fields to watch

PoB-style sources can include assumptions that become outdated after balance changes. Skill scaling, support interactions, passive tree location, item modifiers, and ailment or buff configuration can all shift between patches. Even after a parser exists, a conversion should carry enough version context to explain when the source was captured. Until then, keep patch notes in the manifest or build notes so a future import is not mistaken for a current recommendation.

This is especially important for build guides that circulate long after they were written. A file can be technically parseable while still being strategically obsolete.

FAQ