PokéBonk Type Chart and Same-Type Bonuses

Read the effective chart before importing familiar assumptions

PokéBonk uses familiar type relationships, but its runtime does not simply multiply a hit by the public matrix entry. The game remaps the individual relationship first. That distinction matters when comparing an attack to a target that is weak, resistant or conventionally immune. A standard type chart can identify the relationship without supplying the final coefficient used by this browser game. The effective view above makes that distinction visible.

The current dataset includes 18 types. Rows represent the attacking type and columns represent a defending type. Select a cell to copy that pair into the calculator, or use the selectors when a defender has more than one type. The raw view is available as a source comparison, but its heading deliberately distinguishes it from the gameplay result. This PokéBonk type chart should help you ask a precise question about a hit rather than encourage a blanket rule that an entire Pokémon is always strong against another.

How a single-type matchup is remapped

A raw relationship at or above ×2 becomes ×1.35. A raw immunity value of ×0 becomes ×0.5. Other raw values at or below ×0.5 become ×0.8, and the remaining relationships use ×1. These values come from the runtime effectiveness method. They are not copied from a glossary sentence or inferred from the attack’s color. The order of those conditions matters because an immunity needs its own branch before the general resistance rule.

This means a familiar immunity is not automatically a completely harmless hit under the ordinary extracted calculation. It also means that multiplying an attack by the conventional super-effective coefficient can exaggerate its advantage. The tool displays both the raw relationship and the game’s effective result so you can see exactly where they diverge. Special mechanics may still alter an individual attack or target, which is why the result is labeled a type factor rather than a full damage prediction.

Dual types multiply remapped values and then clamp

For a defender with different types, the runtime evaluates each relationship separately. It multiplies those remapped factors, then limits the matchup result to the interval from ×0.4 through ×1.8. The calculator shows the unclamped remapped product alongside the final matchup so that you can see when the limit changes the answer. It does not multiply the raw matrix first and remap that combined product afterward.

For example, two relationships that each map to ×1.35 produce an intermediate ×1.8225. The final matchup is capped at ×1.8. This cap applies to the matchup component; it is not a cap on every other modifier in the damage calculation. A later matching-type bonus can still multiply that result. Duplicate defending types are not accepted as a substitute for a genuine dual-type target. The selectors remove that ambiguity before any multiplication happens.

Use the Pokédex reference to confirm a species’ types instead of guessing from its appearance. When preparing for an area, consult the map and region guide for the actual context. A useful route may need to handle several different enemy relationships, not merely achieve the largest possible coefficient against a single example.

The same-type attack bonus belongs to the attacker

The same-type attack bonus is a separate question: does the attack’s type match one of the attacker’s types? In the ordinary case, a match gives ×1.25. The player’s Adaptability case uses ×1.5625. An attack that does not match uses the neutral factor. The selected League Pokémon supplies the attacker types and its passive, so the tool can distinguish an ordinary match from the extracted Adaptability condition.

This is not a bonus for merely owning a Pokémon of that type elsewhere in a collection. It also is not established by how many type icons appear across the move slots. A matching move can receive the bonus even while the target resists it, so the final type portion depends on both sides of the calculation. In the build planner, compare the attack class and the partner’s other modifiers alongside the same-type indicator. A nonmatching attack can still be useful for its behavior or coverage.

Captured allies use their own matching-type check

The extracted combat code distinguishes player attacks from captured-allied attacks. An allied attack checks the ally’s types, and a match uses the ordinary same-type bonus. It does not borrow the player’s Adaptability increase simply because the player has that passive. The ally checkbox in this tool applies that distinction to the selected species as an attacker. It is a way to compare the rule, not a simulation of ally acquisition or attack scheduling.

Keep support effects separate from the type factor of an ally’s hit. The client has other systems that can provide modifiers, and their presence does not turn every source of a similarly named type bonus into the same calculation. If a build recommendation includes captured allies, it should state the planned allies and the benefit being discussed. The type chart can answer the matching-attack question while leaving those broader run conditions outside its scope.

Do not confuse cosmetic requirements with combat synergy

Some client data describes type-related research requirements. In this snapshot, those thresholds belong to cosmetic research avatar frames. They are not a verified table of move-count combat bonuses. Labeling them as a requirement to equip a certain number of attacks would create a plausible-looking but incorrect calculator. The PokéBonk type chart therefore marks a move-count synergy system as unextracted instead of reusing unrelated numbers.

You can still build around related types for sensible reasons: an attack may match the partner, an item may boost a type, or a fusion may require a particular pair. Those are specific mechanics with separate evidence. Check the fusion recipe tool for a pair’s actual result and the held-item list for a type item’s description. Avoid treating the phrase “type synergy” as proof of an additional stacking rule when the source only supports one of these narrower interactions.

Use coverage to solve a practical problem

A coverage comparison starts with the opponents you expect and the attack roles you need. Select a troublesome target’s types, then compare attacks that your plan can realistically obtain. Watch both the matchup and the matching-type factor: gaining one may cost the other. The larger factor is informative, but it does not tell you whether the attack tracks its target, reaches through a crowd or stays active while you move. Those behaviors can matter more than a small arithmetic advantage.

Build examples should explain this tradeoff rather than present a type multiplier as a universal ranking. The recommended build collection supplies broader context for equipment and attack roles. You can then use the PokéBonk type chart to test a specific statement, such as whether a proposed coverage move gains enough matchup advantage to offset losing a matching-type bonus. Keep the target and attacker choices in the shared link so another player can reproduce the comparison instead of guessing which situation you meant.

Keep type factors separate from other damage groups

The large result combines the remapped matchup with the applicable same-type bonus. It excludes the attack’s base damage, physical or special scaling, general damage modifiers, critical hits, weather, type-boosting items, defenses and conditional effects. Multiplying every visible percentage in a loadout as though each were an independent damage group can overstate a result. A type factor is most useful when the remaining assumptions stay the same between the options you compare.

The damage calculation overview explains how to separate those groups. The Vitamin reference helps determine which selections affect physical damage, special damage or another stat. A Vitamin that improves an unrelated attack class will not become relevant merely because its icon looks compatible with the move’s type. Likewise, a type item and a same-type attack bonus are separate mechanics even when both benefit the same attack. Use the matching label and the exact item description to keep the reasoning clear.

Version labels and reproducible comparisons

The displayed rules belong to game version 0.8.34, build mvlr7rzv. Both the public matrix and the runtime remapping are saved in the same validated snapshot. When the game changes, the data pipeline must extract and verify the relevant fields before a new set of values can replace the previous snapshot. A parser failure is not a reason to substitute standard Pokémon coefficients or silently retain an unmarked mixture of versions.

Copy link preserves the current attacker, attack, defender types, ally mode and chart view. This is convenient for discussing a comparison, but the displayed version remains part of the evidence. If a later patch changes the rules, repeat the comparison and check the new label rather than treating an old screenshot as current. The source-method page explains how raw data, runtime evidence and unavailable mechanics are distinguished. This unofficial tool reads public game data; it does not modify a game session or guarantee the outcome of a particular run.