Pokémon Size Probability in Pokémon GO

What does the overall probability mean?

It estimates the fraction of Pokémon from the modeled wild-catch population whose displayed or exact height or weight is at least as extreme in the selected direction. “1 in 1,000” is another way to read a probability of 0.001.

Is this a traditional statistical p-value?

No. This app reports a one-sided tail probability under the size model: either the fraction at or below the observation or the fraction at or above it. It does not perform a formal hypothesis test or calculate a two-sided p-value.

How common is each size class in the wild?

The overall wild-catch distribution uses these class weights:

These add to exactly 1. The average class therefore accounts for 94.2% of this model.

Does this mixture apply to every encounter?

We don't know, but probably not. Raid, research, and Team GO Rocket encounters may use different class probabilities, and some events may adjust size rates. No known research data is available for the class weights of non-wild encounters. The overall result should therefore be treated as a wild-catch estimate unless the encounter is known to use the same rates.

Does this calculator apply to Pokémon caught before XXS and XXL?

No. This calculator models Pokémon generated under the current five-class XXS, XS, Average, XL, and XXL size system. XXS and XXL first appeared on December 8, 2022 for Poochyena, Mightyena, and Mawile. The system expanded to all Pokémon on January 17, 2023, during the Season of Mythical Wishes. Those announcement dates are the best practical cutoffs; a precise server-side transition time was not published.

Under the older system, the height variate h_v was drawn from a normal distribution and clamped to the range 0.5–1.5, much like the weight variate w_v. The current system instead chooses a size class first and then draws h_v from that class’s uniform or two-piece distribution. An older Pokémon may appear to fall into the modern XS, Average, or XL height range, but that apparent class does not mean it was generated from the corresponding modern conditional distribution.

The difference affects weight prevalence too, because h_v contributes to the weight formula and is generally squared. Consequently, neither the overall nor the conditional height and weight probabilities on this page are valid for Pokémon generated under the old system. Evolution or trading does not convert an older Pokémon to the new generator; applicability depends on when its original size values were generated.

Does everyone who catches the same Pokémon get the same height and weight?

No. When multiple Trainers catch the same spawn, its size class and weight variate w_v are shared. The height variate h_v is independently randomized for each Trainer within that size class, so the resulting height and weight can differ.

The resulting weights are nevertheless strongly positively correlated between Trainers. Weight is calculated from the shared w_v plus the Trainer-specific height contribution. For example, when catching Rattata or Magikarp, an unusually low or high spawn w_v, respectively, makes a tiny Rattata or large Magikarp more likely for every Trainer. Each Trainer’s independently drawn h_v still affects whether an individual catch crosses the badge threshold.

For example, two Trainers caught the same Average Bidoof spawn and saw different measurements:

• 10.17 kg and 0.41 m implies h_v in [0.81, 0.83) and w_v in 0.81935–0.85265.
• 16.99 kg and 0.5 m implies h_v in [0.99, 1.01) and w_v in 0.82915–0.86965.

The h_v intervals do not overlap, as expected for independently randomized heights. The w_v ranges overlap between 0.82915 and 0.85265, which is consistent with both catches sharing one exact w_v. These are ranges rather than exact values because each displayed height and weight hides an interval of values that round to it.

This behavior has changed over time. Originally, everyone catching the same spawn received the same height and weight. Per-Trainer variation appears to have begun around the introduction of PokéStop Showcases, but the exact transition date is not known. The present behavior is a shared size class and w_v with independently randomized h_v.

Does evolution reroll a Pokémon’s height or weight?

No. Ordinary permanent evolution does not draw new random values. It preserves the Pokémon’s size class and w_v. Normally it also preserves h_v (and therefore normalized height H_n), so the evolved height follows a simple ratio:

The height rule has one exception: when an XXL Pokémon evolves between species with different 1.55, 1.75, or 2.00 XXL height classes, the game maps its relative position in the old XXL range to the same relative position in the new range. This changes h_v and H_n while keeping the height inside the target range. The weight variate w_v remains unchanged. This is deterministic, not a reroll; the Evolution between different XXL height classes section in Technical Details gives the exact mapping.

The evolved weight is therefore predictable too, but it does not generally follow a simple mean ratio. It is recomputed from the preserved w_v, the preserved or remapped h_v, the evolved species’ mean weight, and the applicable weight formula.

The practical obstacle is display rounding, not new randomness during evolution. The game rounds measurements to the nearest hundredth and shows up to two digits after the decimal point, so the displayed height and weight hide the exact variates within rounding intervals. With the exact underlying values the evolved measurements would be deterministic; from displayed values alone, it may only be possible to predict a narrow range of outcomes.

Do Mega Evolution and Primal Reversion use the same height and weight rules as regular evolution?

No. Mega Evolution and Primal Reversion use a separate deterministic height and weight transformation rather than the ordinary evolution rules. They do share that special transformation with each other, and neither rerolls the Pokémon. For brevity, the explanation below uses “Mega Evolution” to include both temporary mechanics.

The transformation is separate from ordinary permanent evolution and appears anomalous. A Pokémon’s position within its original size-class range is calculated first. XXS, XS, and Average heights are then mapped back into the original species’ range, leaving their heights unchanged. XXL is mapped normally into the temporary form’s XXL range. XL mixes the original XL lower boundary with the temporary form’s XL upper boundary, so part of the resulting height range can fall below the temporary form’s nominal XL range.

Temporary-evolution weight is calculated by removing a squared normalized-height contribution based on the original form and adding one based on the new height and temporary form’s means. This calculation squares normalized height in every class, including XXL. If the result would be below zero, the game uses the temporary form’s mean weight instead. The Mega Evolution and Primal Reversion height and weight transformation section in Technical Details gives the complete equations and a measured Mawile example.

Because this transformation does not produce the ordinary normalized height and weight distributions, this app does not report overall or conditional probabilities for Mega Evolutions or Primal Reversions. It still shows their means, class ranges, normalized measurements, and implied variates when those variates remain recoverable.

Does trading reroll a Pokémon’s height or weight?

Not currently. Trading preserves the Pokémon’s existing height and weight. This was not always the case: trades formerly preserved the Pokémon’s size class and w_v but rerolled h_v. The rerolled height produced a new height measurement and, because height contributes to the weight formula, a new weight measurement. This followed the same shared-w_v, randomized-h_v pattern described above for catches. The date when trading changed to preserve both measurements is not known.

What are the conditional class results?

They answer a different question: given that a Pokémon belongs to a particular size class, how unusual is its measurement within that class? Height normally determines the class directly. Weight alone can be possible in several classes because height and weight both contribute to the weight distribution.

Do conditional results show which class is most likely?

No. A result such as “10% of XS Pokémon are this light or lighter” is P(weight ≤ observation | XS); it is not the probability that the observed Pokémon belongs to XS. Estimating class membership from weight would require combining every class’s prior frequency with the probability of observing that weight in each class. This app does not perform that reverse inference.

Why can more than one conditional height class appear?

An exact height determines one size class under the game’s boundary convention. A height displayed after nearest-hundredth rounding represents an interval of possible exact heights, however, and that interval can cross a class boundary. In that case this app shows every class compatible with the displayed value and gives the conditional result within each possible class.

Why are some conditional weight classes grey?

The entered weight lies outside those classes’ possible weight ranges, so a Pokémon with that weight cannot belong to those classes under this model.

What is the difference between Displayed and Exact?

Pokémon GO rounds height and weight to the nearest hundredth but omits unnecessary trailing zeros: for example, values may appear as 1.11 kg, 1.1 kg, or 1 kg. Displayed mode treats an entered value as the full interval that rounds to it; Exact mode treats it as the underlying value. The calculator selects the mode independently for each input: Displayed automatically for values with two or fewer decimal places and Exact for values with more precision.

How does Displayed mode affect Lower and Upper results?

A displayed value of 2.41 represents exact values in the half-open interval [2.405, 2.415). A Lower result therefore counts values that would display as 2.41 or less by looking just below 2.415. An Upper result counts values that would display as 2.41 or more by looking at 2.405 inclusively. This is why the exact value used for a displayed lookup depends on the selected tail direction.

Does the Pokédex use the same rounding as an individual Pokémon?

No. An individual Pokémon’s displayed height and weight use the usual nearest-value convention: a halfway digit rounds up (0.5 toward 1), while a value just below halfway rounds down (for example, 0.4999 toward 0). The size records stored and displayed in the Pokédex use a different rounding convention.

This calculator’s Displayed treatment models the rounded height or weight shown for an individual Pokémon only. It does not model the Pokédex size-record display, so Pokédex record values should not be entered as though they were individual displayed measurements.

Can a Pokémon display a weight of 0 kg?

Yes, for species using the ordinary size system. Any actual weight from 0 kg up to, but not including, 0.005 kg rounds to a displayed weight of 0 kg. The modeled weight ranges of both the XXS and XS size classes extend below 0.005 kg, so every species governed by that system can theoretically display a weight of 0 kg.

The higher a species’ mean weight, the smaller this interval is relative to its usual weight and the less likely the result becomes. At the extreme, Groudon has a mean weight of 950 kg and only about a 1 in 48.1 million chance of displaying 0 kg!

Pumpkaboo is an exception. Its unique four-form size mechanics never produce a weight near zero: Super Pumpkaboo has the lowest possible weight of any Pumpkaboo form at 0.9375 kg. Gourgeist uses the corresponding form-specific system and likewise cannot reach a displayed weight of 0 kg.

Can float32 change an extreme displayed value?

Possibly. Pokémon height and weight are transmitted to the game as IEEE-754 single-precision values (the float32 format). Most decimal values cannot be represented exactly as float32. Usually the difference is far too small to affect the nearest-hundredth display, but a theoretical minimum or maximum ending exactly at a half-cent rounding boundary can move just below that boundary.

The current stats contain three kinds of changed display boundary:

1. Minimum height displays lower: Kyogre’s nominal minimum is 2.205 m, which would round to 2.21 m. Its exact float32 value is 2.2049999237060546875, which should round to 2.2 m.
2. Maximum height displays lower: Kyogre’s nominal maximum is 6.975 m, which would round to 6.98 m. Its exact float32 value is 6.974999904632568359375, which should round to 6.97 m.
3. Maximum weight displays lower: Caterpie’s nominal maximum is 7.975 kg, which would round to 7.98 kg. Its exact float32 value is 7.974999904632568359375, which should round to 7.97 kg.

This behavior is theorized, not verified in practice. Testing it requires finding a Pokémon at the true mathematical minimum or maximum height, or maximum possible weight. Landing exactly at one of those endpoints is so extraordinarily unlikely that no real-world example has come forward. The affected Pokémon are flagged in their result cards, but those notes should be treated as predictions until an endpoint specimen can test them.

How do displayed weights affect the Youngster and Fisher badges?

For the Youngster badge (“tiny Rattata”), the maximum exact weight is 2.40625 kg for both Kanto and Alolan Rattata, even though Alolan Rattata has a higher mean weight. Every Rattata displayed as 2.4 kg or less qualifies, and every Rattata displayed as 2.42 kg or more does not. A displayed weight of 2.41 kg represents [2.405, 2.415) kg, and approximately 1 in 8 Rattata in that interval qualify. The proportion is not exactly 1/8 because weight density is not uniform within the interval; the Technical Details calculation gives the model result for each form.

For the Fisher badge (“big Magikarp”), the minimum exact weight is 13.125 kg. Therefore every Magikarp displayed as 13.13 kg or more qualifies.

Why are probabilities unavailable for Zorua and Zoroark?

Zorua and Zoroark remain selectable so their recorded means and raw height-class ranges can be inspected. Tail probabilities, implied variates, derived weight ranges, and evolution predictions are disabled because Zorua’s disguise-specific size conversion has historically produced measurements outside the ordinary model. Evolving can carry those anomalous measurements into Zoroark. The Zorua’s historical disguise-size transformation entry in Bugs and Suspected Bugs describes the former calculation.

Why are probabilities unavailable for Pumpkaboo and Gourgeist?

Pumpkaboo and Gourgeist remain selectable in their Small, Average, Large, and Super forms so their recorded means and height ranges can be inspected. Each Pumpkaboo form evolves into the matching Gourgeist form.

The four forms use a species-specific size system rather than the ordinary five-class XXS–XXL model represented by this page’s height calculation and precomputed weight CDFs. The page can derive each form’s complete possible weight range, but tail probabilities, implied variates, and evolution predictions remain disabled. The Pumpkaboo and Gourgeist’s form-specific size system section in Technical Details describes the known mechanics.

Why do some Pokémon show unverified size data?

Several regional, alternate, and temporary forms have contradictory or incomplete records in the Game Master. This page keeps them selectable when their recorded means are available, shows the raw extended height settings where possible, and clearly marks those values as unverified. It does not calculate tail probabilities, implied variates, derived weight ranges, or evolution predictions involving an unverified form.

Four alternate forms have form-specific Pokédex mean heights that disagree with the mean implied by their extended size-class bounds:

• Hisuian Lilligant: Pokédex mean 1.2 m; size-class mean 1.1 m.
• Hisuian Avalugg: Pokédex mean 1.4 m; size-class mean 2.0 m.
• Black Kyurem: Pokédex mean 3.3 m; size-class mean 3.0 m.
• White Kyurem: Pokédex mean 3.6 m; size-class mean 3.0 m.

In each case, the extended size bounds appear to have been copied from the ordinary form instead of being adjusted for the alternate form’s mean height. Mega Dragonite, Mega Sharpedo, and Mega Falinks have similar conflicts between their recorded mean heights and extended bounds; Mega Dragonite also has nonstandard XXS and XXL ratios. Mega Skarmory has recorded means but no usable extended size settings. This is likely a Game Master oversight or in-game data bug affecting multiple forms. Showing the source values without deriving probabilities makes the conflict inspectable without guessing which value the game actually uses.

Why are Origin Dialga, Origin Palkia, and Hisuian Decidueye marked unverified?

The weight generator normally uses a standard deviation equal to one eighth of mean weight. These three forms have different weightStdDev values in the Game Master:

• Origin Dialga: 85.375 kg instead of the expected 106.25 kg.
• Origin Palkia: 42 kg instead of the expected 82.5 kg.
• Hisuian Decidueye: 4.575 kg instead of the expected 4.625 kg.

There is strong empirical evidence that Origin Palkia really uses the listed 42 kg standard deviation. A study of n = 45 Origin Palkia inferred the underlying weight variate from each measured height and weight. The maximum-likelihood estimate of the weight standard deviation was 45.5702622386 kg, with a 95% confidence interval of [37.7976833347, 57.3967853809] kg. This interval comfortably includes 42 kg and excludes the otherwise expected 82.5 kg.

The value 42 kg is also revealing: ordinary Palkia has a mean weight of 336 kg, and 336/8 is exactly 42 kg. Origin Dialga follows the same pattern: its listed 85.375 kg is exactly one eighth of ordinary Dialga’s 683 kg mean weight. This strongly suggests that the Origin forms retained their ordinary forms’ absolute weight standard deviations instead of receiving values derived from their own larger mean weights.

The result card reports each recorded standard deviation and its ratio to mean weight. The precomputed weight distributions assume the usual 1/8 ratio, so applying them to these forms would silently contradict their Game Master data. This page therefore shows their available source settings but disables tail probabilities, implied variates, derived weight ranges, and evolution predictions involving them.

What are the three XXL height classes?

XXL begins at 1.5 times a Pokémon’s mean height, but its maximum depends on the species. The three possible upper bounds are 1.55, 1.75, and 2.00 times the mean height: 155%, 175%, or 200% of the species’ average. The calculator reads each Pokémon’s XXL class and selects the matching full and conditional weight distributions.

It is not known what criteria were used to assign an individual species to one of these three XXL classes. The assignments are taken from the species’ size settings rather than inferred from its ordinary height, weight, body shape, or evolutionary relationships.

Most members of an evolutionary family share the same XXL class, but not every family does, so evolution can cross from one class to another. For example, Eevee uses the 1.75 class, while Vaporeon uses the 1.55 class; evolving Eevee into Vaporeon therefore changes the applicable XXL upper bound from 1.75 to 1.55 times the species’ mean height. The other included Eeveelutions also use the 1.55 class.

Within any of these XXL ranges, 95% of XXL heights occupy the first 80% of the range and 5% occupy the final 20%.

How does the XXS height class work?

For most Pokémon, XXS height runs from 0.49 to 0.50 times the species’ mean height. Five percent of XXS heights occupy the first 20% of that narrow range, while 95% occupy the remaining 80%.

The Scatterbug family (Scatterbug, Spewpa, and Vivillon) uses a different XXS range from 0.25 to 0.50 times mean height. Its internal split occurs at 0.30 times the mean, and the calculator uses dedicated full and conditional XXS weight distributions for this family.

Why can XL Pokémon be heavier than XXL Pokémon?

The weight formula squares the height variate h_v for XXS through XL Pokémon, which greatly increases height’s contribution near the top of the XL range. XXL is a special case: its h_v is not squared. As a result, XL Pokémon tend to be much heavier than XXL Pokémon, and an XXL Pokémon can have a lower weight than an XL Pokémon of the same species.

Where do the species data come from?

Species names, forms, mean heights, mean weights, and size bounds were extracted from the Pokémon GO Game Master snapshot used to generate this build’s stats table. This page was built on July 28, 2026. The build script inserts the current local date automatically.

The build date records when this standalone page was generated; it does not verify that the Game Master snapshot or the documented knowledge was current. The person building the page is responsible for obtaining an up-to-date Game Master, regenerating the extracted data, and updating any changed mechanics or research before building.

This is a standalone page and does not dynamically load new Game Master data or behavior updates. It will not reflect Pokémon or forms released after the build date, nor later changes to size mechanics, class rates, existing species data, or known game behavior, until the source data are updated and the page is rebuilt.

Why did I (bmenrigh) undertake this research?

On September 1, 2019, the Silph Research Group published Measuring Up Pokémon, an impressive study based on nearly 50,000 hand-collected measurements. Its second footnote highlighted a remarkable observation posted by Reddit user u/TheParadoxMuse: a Squirtle displayed as weighing only 0.01 kg. The Silph researchers could not reproduce that result in more than 500 million simulations using their proposed model.

That model multiplied an independently sampled random weight by the square of random height. Using the notation defined in the Notation and normalization section of Technical Details, its proposed transformation was:

When I calculated the likelihood of producing such a light Squirtle under that formula, the result was so remote that the observation was effectively impossible.

The article cautiously suggested that the weight distribution might have “slightly heavier tails than a standard normal distribution.” Statistically, that is not a minor adjustment to an otherwise complete model. For a smooth distribution extending from negative to positive infinity, its behavior in the tails determines the prevalence of its most extreme values. An unknown tail shape therefore leaves exactly the rare outcomes of greatest interest unexplained.

After much more data gathering and analysis, I found that the problem was not a slightly different normal-like distribution. It was the transformation itself. Height’s contribution is added to the weight variate rather than multiplied by it:

This additive formula explains the 0.01 kg Squirtle and matches the observed distribution of wild-caught Pokémon weights far more accurately. Later analysis also revealed that the normally distributed weight variate w_v is clamped to the range 0.5–1.5. Under the old size system, the height variate h_v was generated in the same way and separately clamped to that same range.

With fewer than 50,000 hand-recorded samples, detecting those clamps would have been extraordinarily difficult. The original data contained hints that the proposed formula was incomplete, but probably not enough evidence to identify how. Had the researchers dismissed the 0.01 kg Squirtle as a bug instead of documenting it, the discrepancy might never have prompted this investigation. I commend the Silph Research Group for preserving the anomalous result in a footnote: that is how good science moves forward.

Notation and normalization

Throughout this section, H is height in metres and W is weight in kilograms. The species means are μ_H and μ_W. Dividing each measurement by its species mean gives normalized height H_n and normalized weight W_n:

A normalized value of 1 therefore means that species’ average. The calculator performs all probability lookups in H_n or W_n and converts class ranges back to metres and kilograms for display.

The subscript v identifies the two generation variates. The height variate h_v is the generated normalized height, so h_v = H_n. Using both names distinguishes the generation parameter h_v from a normalized measurement H_n, even though their values are equal. The independently drawn weight variate w_v is one input to the weight formula; it is not the final normalized weight W_n.

How the game generates height and weight

The generation order matters. The game does not draw a height and then infer a size class from it; it chooses the size class first and samples from that class’s height range:

1. Choose a size class. The modeled wild class probabilities are 1/250 for XXS, 1/40 for XS, 471/500 for Average, 1/40 for XL, and 1/250 for XXL. Their least common denominator is 1,000: the equivalent integer weights are 4, 25, 942, 25, and 4. The game’s exact random-selection implementation is not known; only the resulting class probabilities matter to this model.
2. Draw the height variate h_v. XS is uniform on [0.5, 0.75], Average on [0.75, 1.25], and XL on [1.25, 1.5]. XXS and XXL use the two-piece distributions described below. Actual height is H = μ_Hh_v.
3. Draw the weight variate w_v. Draw Z from a standard normal distribution, form w_v,raw = 1 + Z/8, and clamp the result to [0.5, 1.5]. This draw is independent of h_v.
4. Combine the variates. Define the transformed-height contribution T_H = h_v² for XXS through XL, but T_H = h_v for XXL. The provisional normalized weight is W_n,0 = w_v + T_H − 1. Actual weight is W = μ_WW_n.

If W_n,0 is zero or negative, the implemented generator does not resample. It replaces w_v with 1.0, making the final normalized weight W_n = T_H.

Exact probability at the weight clamps

Before clamping, w_v,raw has mean 1 and standard deviation 1/8. Both clamp boundaries are exactly four standard deviations from the mean. All draws at or below 0.5 become exactly 0.5, and all draws at or above 1.5 become exactly 1.5. Symmetry gives the same discrete probability mass at both endpoints:

Each endpoint therefore has probability 0.00003167124183311996, or 0.003167124183311996%, about 1 in 31,574.4 weight-variate draws. Together the two clamp masses account for 0.00006334248366623993, or 0.006334248366623993% (about 1 in 15,787.2); the remaining 99.99366575163338% is continuous between the endpoints. The convolution carries these two exact point masses separately from the continuous normal density.

The XXS and XXL height-density steps

XXS and XXL are not uniform across their complete height ranges. Each is made by first choosing one of two adjacent subranges and then drawing uniformly within the chosen subrange. There is no gap and no discrete mass at the boundary, but the PDF is a step function: its height changes abruptly while its CDF remains continuous.

Let d_small = 0.5 − h_v,min. For XXS, 1/20 of the class lands uniformly in the lowest 20% of its h_v range, while 19/20 lands uniformly in the upper 80%:

The density is therefore 0.25/d_small below the split and 1.1875/d_small above it: an upward jump by a factor of 4.75. For ordinary species the split is at 0.492; for the Scatterbug family it is at 0.30.

XXL reverses the arrangement. Let d_large = h_v,max − 1.5. The first 80% of the h_v range receives 19/20 of XXL Pokémon and the final 20% receives 1/20:

Its density consequently steps downward by the same factor of 4.75. The split points are 1.54, 1.70, and 1.90 for the 1.55, 1.75, and 2.00 XXL classes.

Evolution between different XXL height classes

Ordinary evolution preserves h_v, so multiplying H by the ratio of the new and old mean heights leaves normalized height H_n unchanged. That rule is insufficient for an XXL evolution when the two species have different XXL upper bounds. An h_v valid in a 1.75 or 2.00 class could otherwise lie beyond the maximum of a target species in the 1.55 class.

The game instead preserves the Pokémon’s relative position through the complete XXL interval. Let H_s be the source height, μ_H,s and μ_H,t the source and target mean heights, and c_s and c_t their XXL upper-bound classes. First calculate the source fraction q, where 0 is the common 1.5× lower boundary and 1 is the source maximum. Apply that same fraction between the target boundaries:

Equivalently, h_v (and therefore H_n) is linearly remapped from [1.5, c_s] to [1.5, c_t]. Both endpoints and the internal 80% density-step boundary map exactly to their counterparts in the target class.

For example, Skorupi has mean height 0.8 m and uses the 1.75 XXL class. An XXL Skorupi measuring 1.22 m is 10% of the way from its 1.20 m XXL minimum to its 1.40 m maximum. Drapion has mean height 1.3 m and uses the 1.55 class, whose XXL interval is 1.95–2.015 m. Placing the evolved Pokémon 10% through that interval gives:

The evolved Drapion therefore displays as 1.96 m. Its h_v and H_n change from 1.525 to 1.505. Its w_v remains unchanged: the target’s XXL weight equation uses the preserved w_v, the remapped h_v, and Drapion’s mean weight.

A measured Noibat evolution provides a useful check. Noibat has mean height 0.5 m and a 1.75 XXL class; Noivern has mean height 1.5 m and a 1.55 class. Taking the displayed 0.82 m as the center gives a source h_v of 1.64, 56% through the XXL range. Remapping gives h_v = 1.528 for Noivern, or H = 2.292 m, which displays as 2.29 m. Because the source measurements were displayed as 0.82 m and 11.84 kg rather than known exactly, preserving w_v predicts an evolved displayed weight between 115.55 and 117.01 kg. The observed Noivern was 2.29 m and 115.93 kg, matching both the height remapping and preservation of w_v. Additional checked evolutions, including significant w_v outliers, confirm that w_v is preserved rather than rerolled.

Mega Evolution and Primal Reversion height and weight transformation

Mega Evolution and Primal Reversion use the same mechanics. For brevity, this section calls the resulting temporary form “Mega” and uses subscript M for either kind. Neither uses the ordinary evolution formulas above. Observed results instead show a deterministic class-position mapping followed by a separate weight correction. Let [L_o, U_o] be the original form’s height interval for the Pokémon’s size class, and [L_M, U_M] the corresponding temporary-form interval. The game first calculates the original height’s fractional position q through its class:

The mapping back to height depends on the class:

Thus XXS, XS, and Average Pokémon retain their original absolute height even when the Mega form has a different mean. XXL behaves as an ordinary proportional remapping between the complete source and target intervals. XL is asymmetric: it uses the original XL lower boundary but the Mega XL upper boundary. It does not use L_M, so the lower part of the mapped range may not lie in the Mega form’s nominal XL interval. At the upper end, this malformed XL range can cross into the temporary form’s XXL height range. An originally XL Pokémon can therefore appear to change into the XXL class, and its displayed size label changes to XXL for the duration of the Mega Evolution or Primal Reversion. The no-change mappings and especially this mixed-boundary XL formula appear unintended, but the game’s intent is not known.

After obtaining H_M, the game first calculates a raw Mega weight from the original measurements and both forms’ means. With subscripts o and M denoting the original and Mega forms:

If this raw result is below zero, observed results show that the game replaces it with the Mega form’s mean weight. Positive raw results retain their calculated weight. The behavior at exactly zero has not been observed:

This fallback matters primarily for some XL transformations, where the mixed-boundary height mapping can make the subtracted original contribution larger than the other two terms combined. It creates a discontinuity between negative raw results close to zero, which become the mean weight, and positive raw results close to zero, which remain close to zero. What happens at exactly zero remains untested, and finding a specimen at that precise boundary is extraordinarily unlikely. The prediction code must choose a boundary convention, so it treats exact zero as zero and checks the raw formula’s zero crossings explicitly; an input interval that straddles one can produce both near-zero weights and the mean-weight fallback.

The raw formula subtracts a squared normalized-height weight contribution calculated from the original form, then adds the corresponding contribution calculated from the mapped Mega height and Mega means. Unlike initial weight generation, this transformation squares normalized height for every size class (including XXL), whose original generation formula uses an unsquared height contribution. It does not simply preserve w_v across the two forms.

A speculative interpretation of the weight formula

The game’s intent is not documented, but the algebra suggests a coherent original design. Define a height-derived baseline weight B for any form:

Before applying the negative-weight fallback, the temporary-evolution formula can be rewritten as a baseline replacement:

In this interpretation, the bracketed term W_o − B_o is the individual Pokémon’s residual weight above or below the source form’s height-derived baseline. The game removes the old baseline, preserves that residual as an absolute number of kilograms, and adds the temporary form’s new baseline. Unless the result invokes the mean-weight fallback, a Pokémon exactly on the old baseline remains exactly on the new baseline; one 5 kg above or below it remains 5 kg above or below it.

For an ordinary XXS-through-XL Pokémon, H_n,o = h_v and the generation formula makes the preserved residual especially clear:

This preserves an absolute weight residual, not the dimensionless weight variate. If a nonnegative raw result is interpreted through the ordinary squared-height formula, its effective temporary-form variate is:

True preservation of w_v would instead scale the old residual by μ_W,M/μ_W,o before adding it to the new baseline. The implemented formula omits that ratio. Preserving kilograms may have been intentional, or the residual may have been treated as though it were already normalized; observations reveal the operation but cannot distinguish those design motives.

XXL is the strongest evidence that this may be legacy behavior. Modern XXL generation uses the unsquared contribution h_v, yet temporary evolution still subtracts and adds squared-height baselines. Its preserved residual is therefore μ_W,o(w_v,o + h_v,o − 1 − h_v,o²), which still contains a height-dependent term and no longer cleanly represents independent weight variation. Mega Evolution launched on August 27, 2020, while XXS and XXL first appeared on December 8, 2022. A plausible (but unconfirmed) explanation is that the weight transform was designed for Mega Evolution under the older universally squared-height system, left unchanged when the special XXL rule was added, and later reused for Primal Reversion.

For example, Mawile’s XXL range is 0.915–1.0675 m and Mega Mawile’s is 1.5–1.75 m. An XXL Mawile displayed as 0.96 m and 17.18 kg represents exact inputs H_o in [0.955, 0.965) m and W_o in [17.175, 17.185) kg. Applying the XXL position mapping and weight equation gives H_M in [1.56557, 1.58197) m and W_M in approximately [46.5873, 47.2164) kg. The observed Mega Mawile displayed as 1.58 m and 47.2 kg, which lies within both predicted ranges.

When both temporary-form height and weight are supplied, this page normally reverses the applicable class mapping to recover H_o, then reverses the weight correction:

The original h_v is H_o/μ_H,o. Substituting H_o and W_o into the ordinary generation formula recovers the original w_v, using the squared-height branch for XXS through XL and the linear-height branch for XXL. Displayed measurements are reversed as intervals, so the page reports every compatible class and variate range rather than pretending the rounded inputs are exact. The exception is a temporary-form weight equal to (or whose displayed interval includes) the form’s mean: it may have come from the negative-weight fallback, which discards the raw result and makes the original w_v impossible to recover uniquely. The page flags that ambiguity instead of reporting a misleading inverse.

The embedded height distributions and weight CDFs describe Pokémon generated directly by the ordinary five-class model. Applying them to a Mega or Primal form as though its measurements had been freshly generated from the temporary form’s means and bounds would give invalid probabilities. Mega and Primal entries therefore retain descriptive range and variate calculations, but all overall and conditional probability lookups are deliberately disabled.

Why the weight distribution is not estimated by random sampling

A Monte Carlo simulation is straightforward: randomly choose a size class, draw h_v, draw w_v, combine them, and count the resulting W_n in a bucket. It is not precise enough for this job. A sampled PDF is visibly noisy even after hundreds of billions of generated Pokémon.

The difficulty is that the PDF is divided into buckets only 0.000001 normalized-weight units wide. Many individual buckets (especially in the tails) have tiny probabilities. If a bucket has probability p and the simulation makes N draws, it receives only Np samples on average, and its relative sampling noise is roughly proportional to 1/√(Np). Increasing an already enormous simulation reduces noise only by the square root of the extra work. Rare-tail buckets remain noisy, and accumulating those errors damages the tail probabilities this tool is intended to measure.

The generated tables therefore contain no Monte Carlo sampling noise. They come from deterministic numerical convolution of the input distributions.

The exact input distributions

The h_v distribution is known analytically. Each size class is uniform over one or two fixed intervals. The overall wild model mixes those intervals using the XXS, XS, Average, XL, and XXL probabilities listed in the FAQ. XXS and XXL have their internal 1-to-19 splits, and the outer endpoints come from the species’ XXS and XXL classes.

The w_v distribution is known analytically as well. Its continuous bucket integrals are calculated from differences of the normal CDF (the error function), while the exact masses created by clamping at 0.5 and 1.5 are handled explicitly. The squared or linear transformation from h_v to T_H is evaluated analytically before discretization, and the nonpositive-result rule is applied during convolution at the grid’s finite resolution. These transformations explain both the shape of the W_n PDF and why the XXL weight range can begin below the XL range.

High-resolution numerical convolution

The T_H and w_v distributions are first integrated over a grid with width Δx = 10⁻⁶. Each bucket integral comes from subtracting analytic CDF values at its two edges, not from sampling. The implementation stores transformed-height bucket mass and the corresponding average weight density; the factor of Δx relating mass and density is accounted for by the discrete convolution. Constructing T_H applies the inverse square-root transformation where h_v was squared and the linear inverse transformation for XXL.

Away from the nonpositive-result fallback, the two independent distributions are then convolved. Let A = T_H − 1 be the transformed-height offset. For every possible offset a and weight variate w_v, their contributions are multiplied and added to the bucket for W_n = a + w_v:

Combinations whose provisional W_n,0 is nonpositive are routed instead to W_n = T_H, as required by the weight-variate reset. The implementation performs this convolution and routing at high resolution, handles the clamped endpoint masses separately, and splits contributions across neighboring output buckets to retain left-edge alignment. Because every input bucket integral is derived from an analytic CDF, the result is a deterministic numerical integration rather than a random estimate.

The resulting W_n PDF spans 0 through 2.75 and contains 2,750,001 rows at millionth-unit spacing for each distribution. Separate convolutions produce the three full XXL variants, the Scatterbug-family mixture, and the conditional XXS, XS, Average, XL, and XXL distributions.

PDF density versus CDF probability

The direct result of convolution is the probability density function (PDF) f_Wₙ(x). A PDF value describes how concentrated probability is near a normalized weight W_n; it is not itself the probability of observing that exact weight. In the continuous parts of the model, probability comes from the area under the PDF across an interval. The w_v input also has discrete boundary masses introduced by clamping; those are carried through the convolution explicitly rather than being mistaken for ordinary density.

This distinction matters for interpretation. A large density says that nearby weights are locally common, but it does not answer “How many Pokémon are this light or lighter?” or “How many are this heavy or heavier?” Those are cumulative, one-sided tail questions.

The resulting PDF is piecewise smooth, not globally differentiable. Three parts of the generation algorithm create non-smooth features:

• Clamping w_v creates point masses at 0.5 and 1.5. Convolution with the continuous T_H distribution spreads each mass into a shifted copy of that density, including its edges and density steps.
• The XXS and XXL h_v PDFs change density abruptly at their internal 5%/95% boundaries. Their transformed T_H contributions carry those step changes into the W_n PDF.
• When W_n,0 is nonpositive, replacing w_v with 1 concentrates all such outcomes onto W_n = T_H. This adds another component shaped by the T_H distribution, with its own sharp boundaries.

Depending on how these components meet, the weight PDF can have jump discontinuities (the density itself changes instantly) or kinks (the density is continuous but its slope changes instantly). “Discontinuity” is correct for the former, but non-smooth breakpoint is the useful general term covering both.

The lower cumulative distribution function (CDF) integrates all PDF area from the minimum possible W_n through x. The survival function integrates in the opposite direction:

Integration smooths these features but does not erase them. The final-weight distribution has no point masses because height remains continuously distributed, so its CDF is continuous. A jump in the PDF becomes an abrupt change in CDF slope, making the CDF nondifferentiable at that point; a PDF kink appears as a change in the CDF’s curvature. The survival function has the same non-smooth locations.

The expensive convolution builds the high-resolution PDF, but that large PDF is not included in this page. It is integrated once during the build process, and this page stores compact polynomial representations of the resulting CDF and survival functions. This app therefore answers tail-probability questions, not point-density questions.

Converting the PDF into accurate lower and upper tails

Every raw W_n PDF value is aligned to the left edge of its bucket. Its probability mass is the density multiplied by the distance to the next coordinate. All bucket masses are summed and normalized so that the total area is exactly 1 at output precision.

The lower-tail CDF is accumulated from left to right. The survival function (the upper-tail probability) is accumulated independently from right to left. Both directions use compensated floating-point summation. Computing the survival tail independently is important: obtaining a tiny upper-tail probability by subtracting a CDF near 1 would discard many significant digits.

The uncompressed table stores the coordinate, CDF, and survival value with 17 significant decimal digits. This is highly accurate but far too large to embed directly in a small offline page.

Compressing millions of CDF points into fifth-order polynomials

The compressor replaces long runs of table rows with best-fit degree-5 polynomial segments. For a candidate segment from x₀ to x₁, the coordinate is first rescaled to u in [0, 1]. The polynomial is represented in an endpoint-constrained form:

Here y₀ and y₁ are the exact table values at the segment endpoints and Q(u) is a cubic. Multiplying the cubic by u(1−u) produces a polynomial of degree at most five. That factor is zero at both endpoints, so every fitted segment is forced to reproduce y₀ and y₁ exactly.

Adjacent segments share their endpoint. Fixing both endpoint values therefore prevents jumps at segment boundaries; the representation guarantees value continuity even though it does not require equal derivatives on the two sides.

Fitting, validation, and segment selection

The four coefficients of Q are found by weighted least squares over all interior points. Values closer to zero receive proportionally greater weight so that relative error, rather than only absolute error, controls the tails. The candidate is then evaluated at every original grid point it covers.

A segment is accepted only when all of these checks pass:

• Every nonzero source value has relative error below 10⁻⁹.
• Every exact zero is reconstructed as exactly zero.
• The polynomial remains monotone over the entire continuous segment, checked from the derivative and its interior extrema.
• A small safety margin remains for coefficient serialization and evaluation by this page.

Starting at each endpoint, the compressor uses exponential probes to find a failing bound and then binary search to select a long passing endpoint within that bracket. That greedy process repeats until the entire table is covered. Acceptance of a fitted segment is not mathematically guaranteed to be monotone as its endpoint moves, so this search is a compression heuristic rather than proof of the globally longest possible segment. This can affect the number of stored segments, but not their accuracy: every segment that is actually emitted has independently passed all pointwise-error and continuous-monotonicity checks above.

This exhaustive point-by-point validation is what preserves the non-smooth CDF features. The compressor does not need to know their locations beforehand. A candidate polynomial that stretches across a sharp slope or curvature change will normally exceed the error bound, causing the accepted segment to end at or immediately beside that breakpoint. The next polynomial then starts from the same exact source value, and independent derivatives on the two sides allow it to represent the abrupt change. If one polynomial can cross a milder feature, it is accepted only after reproducing every millionth-spaced source value within the 10⁻⁹ bound. A feature is therefore captured either by a polynomial boundary or by a segment that has been explicitly verified across it.

Why both CDF and survival polynomials are stored

A relative-error bound on the CDF does not protect a tiny upper tail. For example, when CDF = 0.999999999, a seemingly tiny CDF error can be comparable to (or larger than) the entire survival probability of 0.000000001. Subtracting the fitted CDF from 1 would make “1 in a billion” results unreliable.

To prevent that, the lower half of each table fits CDF values directly, while the upper half fits independently accumulated survival values directly. The representation switches near the point where CDF and survival cross. At that shared boundary, the first survival value is explicitly made the exact complement of the preceding CDF value, preserving continuity.

The 10⁻⁹ relative-error requirement is applied to whichever tail is smaller and therefore numerically sensitive. This keeps both the displayed probability and its reciprocal “1 in N” interpretation within the target error across the tails. The requirement is checked at every millionth-spaced source point; monotonicity prevents unphysical oscillations between those points.

Why height needs no polynomial compression

The H_n distribution (equivalently, the h_v distribution) is well behaved and can be evaluated directly. Its PDF is constant within each of the class subranges described above, so integrating it produces an exact piecewise-linear CDF. For a height lookup, this app converts H to H_n, locates the containing subrange, adds the complete probability of every preceding subrange, and adds the appropriate linear fraction of the current one. The upper tail is computed from the same exact interval probabilities.

No numerical convolution, millionth-spaced table, or fitted polynomial is needed for height. The complex PDF construction and degree-5 CDF/survival compression described above apply only to weight.

How this page performs a lookup

The finished page embeds 837 polynomial segments across 12 distributions. Their markers, endpoints, and coefficients are stored as compact base64-encoded float64 records, preserving the values written by the compressor without verbose decimal text.

For a lookup, JavaScript converts W to W_n, selects the full or conditional distribution from the Pokémon’s XXS and XXL classes, uses binary search to locate the segment containing W_n, rescales that coordinate to u, and evaluates the polynomial with Horner’s method. A segment marked C stores the CDF; a segment marked S stores survival. In either half, the smaller and more sensitive tail is stored directly; the larger complementary tail can then be calculated safely as 1 minus that small value.

Distribution selection and displayed values

The Pokémon’s XXL class selects the 1.55, 1.75, or 2.00 full and conditional XXL distributions. Scatterbug, Spewpa, and Vivillon use their dedicated 0.25 XXS distributions and the 1.75 XXL distribution.

A displayed value such as 2.41 represents the half-open interval [2.405, 2.415). Lower-tail calculations use the greatest representable value below 2.415; upper-tail calculations use 2.405 inclusively.

The 2.41 kg Rattata badge calculation

The Youngster cutoff is 2.40625 kg, while a displayed weight of 2.41 kg represents [2.405, 2.415) kg. The qualifying fraction among Rattata displaying 2.41 kg must therefore be calculated from CDF differences, not from the fraction of the interval’s width. If F is the applicable full-distribution CDF and μ_W is the form’s mean weight:

Using the uncompressed numerical CDF, Kanto Rattata (μ_W = 3.5 kg) has qualifying probability mass 0.000338992407044381 within a complete displayed 2.41 interval of probability mass 0.00271769332803123. Their ratio is 0.124735342118220, or 12.4735342118220% (about 1 in 8.01697404295).

For Alolan Rattata (μ_W = 3.8 kg), the corresponding masses are 0.000274127877442298 and 0.00220090590529395. Their ratio is 0.124552293118449, or 12.4552293118449% (about 1 in 8.02875623533). The two proportions differ because the same absolute-weight interval occupies different normalized-weight locations for the two forms. These figures are “exact” within the uncompressed millionth-grid numerical model; the model’s discretization and floating-point limitations still apply.

Pumpkaboo and Gourgeist’s form-specific size system

Pumpkaboo and Gourgeist do not use the ordinary size system described above. Each has four form categories with separate dimensional means and ranges. The category is preserved by evolution: Small Pumpkaboo evolves into Small Gourgeist, Average into Average, Large into Large, and Super into Super.

Small, Average, and Large Pumpkaboo have heights at or above their form mean. Super reverses that relationship: its entire height range is at or below its 0.8 m mean. Gourgeist retains the same form category after evolution, with the corresponding means and ranges shown above.

Within each Pumpkaboo or Gourgeist form, normalized height is still h_v = H/μ_H. The weight variate is normally distributed around 1 with standard deviation 1/8 and clamped to [0.5, 1.5], exactly as in the ordinary model. Weight always uses the squared-height formula, including for Super:

This reversal makes Super (not Small as you would naively assume) the form capable of the lowest possible Pumpkaboo weight. At the Super minimum height of 0.6 m and lower weight clamp of 0.5:

The weight ranges in the table are obtained by combining each form’s minimum height with w_v = 0.5 and its maximum height with w_v = 1.5. The source means and ranges are embedded in this page, but its ordinary height distribution and weight CDFs do not model this four-form system. The page therefore shows the source measurements and exact possible ranges while deliberately withholding probabilities and evolution predictions. See the original Pumpkaboo mechanics research for the underlying observations.

Accuracy and model limitations

Every practical care has been taken to make this calculator as accurate as possible: the input distributions are evaluated analytically, the weight PDF is built by deterministic high-resolution convolution, the two tails are accumulated separately with compensated summation, polynomial endpoints are fixed exactly, and every source point is checked against a strict error bound. These measures are intended to make error introduced by this page negligible compared with the limitations of the source data and the game itself.

The 10⁻⁹ relative-error target describes polynomial-compression error, not total error relative to real Pokémon encounters. It compares each fitted CDF or survival polynomial with the high-resolution numerical table from which it was built. That source table is itself a deterministic float64 approximation produced on a grid with spacing 10⁻⁶; it has discretization and floating-point error even though it has no Monte Carlo sampling noise.

The relative-error requirement is checked at every millionth-spaced source coordinate. Between those coordinates, the polynomial is guaranteed to remain monotone and its endpoints are fixed exactly, but there is no separate formal 10⁻⁹ relative-error proof for every real number between grid points. The extremely dense grid and degree-5 shape make unobserved error unlikely, but the stated numerical guarantee is point-by-point at the source coordinates.

Numerical precision is also different from model accuracy. Results assume that the Game Master means and size bounds are correct and that the documented height and weight transformations are used. The Overall population result additionally assumes the modeled wild mixture: 1/250 XXS, 1/40 XS, 471/500 Average, 1/40 XL, and 1/250 XXL. If an encounter type (such as research, raids, Team GO Rocket, or an event) uses different or unknown class weights, the Overall population result will not describe that encounter population correctly. In that case, only the per-class conditional probability is meaningful once the Pokémon’s actual size class is known, because that result does not depend on how frequently the different classes occur.

Data mistakes, encounter-specific behavior, event bonuses, or future game changes can matter far more than polynomial-fitting error.

The weight distributions model continuously valued height and weight before transmission. They do not quantize every generated outcome onto the complete float32 value lattice. Some species’ possible height or weight ranges contain fewer than one billion distinct float32 values, so “one in a billion” numerical accuracy cannot literally correspond to a billion independently distinguishable in-game measurements in those ranges. The 10⁻⁹ target is still useful as a conservative fitting tolerance: it ensures that polynomial compression contributes far less error than the game’s own numerical resolution.

Displayed mode accounts for the nearest-hundredth interval represented by an individual measurement, and this page flags theorized float32 changes at exact extrema, but the full CDF tables do not model every tiny probability change that float32 quantization could introduce. The result is as accurate as practically achievable under the documented model, but finite numerical resolution, discretization, imperfect source data, and unknown or changing game behavior prevent perfect accuracy from being possible.

Offline and reproducible

Pokémon statistics and polynomial coefficients are embedded directly in this file. The calculator makes no network requests and performs every lookup locally in your browser. The standalone page is generated from the stats table and compressed CDF files, so it can be rebuilt whenever either source changes.

The source code and data-processing tools needed to reproduce this application are available at github.com/bmenrigh/pogo_size.

Inferred model versus internal implementation

The algorithms described on this page are inferred from Game Master data and measured game behavior; they are not a transcription of server or game source code. Within every testable case devised so far, the model reproduces observed height and weight behavior exactly. The main unresolved qualifications concern floating-point behavior at precision that the game’s rounded display makes extraordinarily difficult (usually effectively impossible) to test.

The 1.55, 1.75, and 2.00 “XXL height classes” are useful derived categories, but they do not appear as categorical values in the Game Master. Instead, each form’s height boundaries are stored directly in metres. The XXL upper multiplier is recovered by dividing the stored upper boundary by that form’s mean height. In other words, a boundary described here as 1.75 × mean height is already multiplied out in the source data. The relevant weight means and standard deviations are likewise stored in kilograms rather than as normalized values.

This suggests that the real implementation may operate directly on dimensional boundaries without ever constructing the normalized intermediates used in this explanation. For example, what this page describes as an XXL evolution between different derived height classes may simply be the ordinary operation used for every XXL evolution: calculate the Pokémon’s fractional position within the source form’s stored range, then map that fraction into the target form’s stored range. Such an implementation would handle different upper-bound ratios naturally, with no special “XXL class changed” branch and perhaps no explicit normalized-height value.

That distinction does not affect the modeled results when the two formulations are algebraically equivalent after a change of variables. The normalized formulation is valuable because it reveals that almost every form falls into one of three reusable XXL distributions, allowing the same CDFs to serve many species even if the game itself never names those categories.

Algebraic equivalence under exact arithmetic does not guarantee bit-for-bit equality under floating-point arithmetic. Reordering operations, working directly in metres or kilograms, choosing float32 or a wider intermediate, and rounding at different stages can change a result by one or more units in the last place (ULPs). Reverse-engineering the exact operation order to that level would require exact underlying measurements that the game normally hides behind two-decimal display rounding. It would be extremely difficult, potentially impossible for some edge cases, and would provide no practical improvement to the probabilities reported here. Consequently, this page aims to reproduce observable behavior as accurately as practical, not to claim a verified instruction-for-instruction implementation.

This section collects the apparent game bugs, data problems, and unverified edge cases discussed elsewhere on this page. “Suspected” means that observed behavior or published data appear internally inconsistent; it does not mean the issue has been acknowledged by the game’s developers.

Mega Evolution and Primal Reversion height mapping

Observed behavior; intent unknown. XXL correctly maps a Pokémon’s relative position from the original form’s complete XXL range into the temporary form’s XXL range. The other classes are inconsistent with that pattern. XXS, XS, and Average map back into the original form’s range, leaving absolute height unchanged even when the temporary form has a different mean. XL combines the original form’s lower boundary with the temporary form’s upper boundary, which can place the result outside the temporary form’s nominal XL range. The no-change mappings appear to be an oversight, while the mixed-boundary XL mapping appears to be a bug.

Mega Evolution and Primal Reversion weight transformation

Observed behavior; likely legacy logic. The temporary-evolution weight calculation subtracts and adds squared normalized-height contributions in every class. That conflicts with modern XXL generation, which uses an unsquared height contribution. A plausible explanation is that the weight transform predates XXS and XXL and was never updated for the special XXL rule. The calculation can also produce a negative raw weight; the game replaces any negative result with the temporary form’s mean weight, creating a discontinuity and discarding information needed to reverse the transformation. These mechanics are why this page does not report probabilities for Mega Evolutions or Primal Reversions.

Contradictory Game Master form data

Likely data oversights. Several Game Master templates are missing the records needed to interpret them or contain mutually incompatible means and size bounds. When recorded means exist, this page retains the form as unverified and shows its raw extended height settings where available, but disables probability calculations and evolution predictions involving it. A template with no matching Pokémon settings cannot supply even the required means and remains unusable unless another complete record describes the same form.

Extended settings without matching Pokémon settings

• V0902_POKEMON_BASCULEGION, V0902_POKEMON_BASCULEGION_FEMALE, and V0902_POKEMON_BASCULEGION_NORMAL have extended settings but no matching pokemonSettings record from which to obtain the required mean weight and other base data.
• V999_POKEMON_GIMMIGHOUL likewise has no matching pokemonSettings record. This unmatched template is ignored; Gimmighoul remains available through its separate valid records.

Ordinary-form mean-height contradictions

Four alternate forms have a Pokédex mean height that disagrees with the mean implied by their extended size-class bounds:

• Hisuian Lilligant: 1.2 m Pokédex mean versus 1.1 m size-class mean.
• Hisuian Avalugg: 1.4 m Pokédex mean versus 2.0 m size-class mean.
• Black Kyurem: 3.3 m Pokédex mean versus 3.0 m size-class mean.
• White Kyurem: 3.6 m Pokédex mean versus 3.0 m size-class mean.

These bounds appear to have been copied from the ordinary forms without being adjusted for the alternate forms’ heights.

Mega settings contradictions

• Mega Dragonite’s size settings imply a mean height of 3.36875 m, but its averageHeightM is 2.2 m. Its implied XXS ratio is 0.56 rather than an allowed 0.25 or 0.49, and its implied XXL ratio is approximately 1.71428571429 rather than 1.55, 1.75, or 2.00.
• Mega Skarmory’s extended size settings are missing or invalid.
• Mega Sharpedo’s size settings imply a mean height of 2.5 m, but its averageHeightM is 1.8 m.
• Mega Falinks’s size settings imply a mean height of 3.0 m, but its averageHeightM is 1.6 m.

Mega Dragonite has a particularly revealing numerical pattern. Regular Dragonite and Mega Dragonite both have a recorded mean height of 2.2 m. Regular Dragonite belongs to the 1.75 XXL class, making its ordinary maximum height exactly 2.2 × 1.75 = 3.85 m. Every stored Mega Dragonite boundary is an exact multiple of that ordinary 3.85 m maximum:

The complete Mega table is therefore exactly 3.85 × [0.49, 0.50, 0.75, 1.00, 1.25, 1.50]. It appears that regular Dragonite’s maximum height may have been used as though it were Mega Dragonite’s mean. The upper half also uses 1.00, 1.25, and 1.50 where ordinary 1.75-class settings would use 1.25, 1.50, and 1.75. This is not a simple copy of the ordinary table, but it suggests some familiar structure nonetheless.

If Mega Dragonite’s recorded 2.2 m mean and Dragonite’s ordinary 1.75 XXL class were used normally, its boundaries would be [1.078, 1.1, 1.65, 2.75, 3.3, 3.85] m (the same as regular Dragonite’s because their recorded means match). Instead, the stored Average interval is 2.8875–3.85 m, whose midpoint is the 3.36875 m reported above. No other Pokémon has a mean height with more than two decimal digits of precision. This structured relationship strongly suggests a configuration-generation or data-entry error rather than an intentional alternate size system.

Weight standard-deviation contradictions

Origin Dialga, Origin Palkia, and Hisuian Decidueye specify a weightStdDev other than one eighth of mean weight.

In all three cases, the unusual value exactly matches the ordinary form’s standard deviation: Origin Dialga retains Dialga’s 85.375 kg, Origin Palkia retains Palkia’s 42 kg, and Hisuian Decidueye retains Decidueye’s 4.575 kg. This repeated pattern is likely a Game Master oversight in which the alternate forms inherited their ordinary forms’ absolute standard deviations even though their mean weights changed.

The other two Hisuian final-stage starters also have different mean weights from their ordinary forms, but their standard deviations were correctly recalculated as one eighth of the new mean. Hisuian Decidueye is the lone exception:

This comparison makes a copy or inheritance mistake particularly likely: the value was adjusted for Hisuian Typhlosion and Hisuian Samurott, but not for Hisuian Decidueye. Its small 0.05 kg discrepancy may simply have escaped notice.

These forms remain selectable so their conflicting source data can be inspected. Their means are marked unverified, and this page does not guess which values or size classes should be used for statistical calculations.

Zorua’s historical disguise-size transformation

Historical anomalous behavior. Zorua encounters appear disguised as the Trainer’s buddy. Historically, converting the disguise measurements back into Zorua measurements did not simply retain an ordinary Zorua height and weight. The conversion mixed the buddy species’ means, the visible disguise measurements, the underlying Zorua size branch, and clamps to Zorua’s allowed height range. MocTalox’s (Riff's) Ultra Massive Zoruas analysis reconstructs the observed calculation and its edge cases.

The linked analysis first divides the disguise height and weight by the buddy species’ mean height and weight. It calls the resulting normalized values h_n and w_n, then removes the applicable transformed-height contribution to obtain a residual called k: subtract h_n² for the ordinary squared-height branch or h_n for the XXL linear branch.

Thus the analysis’s k is exactly this page’s w_v − 1, not a separate random variable. This page keeps w_v centered at 1 and writes the explicit “− 1” in the weight formula. The historical Zorua analysis instead uses the zero-centered k; the subtraction is already absorbed into k before the transformed-height term is added back.

The conversion then maps the buddy-normalized height into Zorua’s range. Below the XXL branch it uses at least 0.49; in the XXL branch it uses no more than 1.75, although the source documents evidence that one XXL edge may have been forced directly to 1.75. It reconstructs normalized Zorua weight as:

For inputs already inside the intended ranges, adding k reconstructs the familiar w_v + T(h_v) − 1 form. The bug arises because the height and residual came through the buddy disguise transformation and were then bounded or branched as Zorua. Extreme mismatches between buddy and Zorua species dimensions could therefore produce “Ultra Massive” Zorua, while some low-residual XXL cases collapsed to a fixed height-derived weight. The linked research enumerates separate branches for whether the underlying Zorua and the buddy-normalized disguise were below, within, or above their expected ranges, and notes a few branches that lacked test data.

Zorua and Zoroark are retained in this page as unverified rather than omitted, allowing their Game Master means and raw class boundaries to be inspected. Probability calculations are disabled: the precomputed CDFs describe the ordinary generator, not this historical disguise conversion or anomalous measurements inherited by Zoroark through evolution.

Pumpkaboo and Gourgeist’s nonstandard size system

Special case; not necessarily a bug. Pumpkaboo and Gourgeist use four matched form categories with height ranges and means that do not follow the ordinary five-class model. The forms are retained so their source data and exact possible weight ranges can be inspected, but probability and evolution calculations are disabled. The complete known rules and form table appear under Pumpkaboo and Gourgeist’s form-specific size system in Technical Details.

Display rounding and float32 endpoints

Theorized and not yet observed in practice. Height and weight are transmitted as float32 values. At a mathematical endpoint that lies exactly on a nearest-hundredth rounding boundary, float32 representation can move the value just below that boundary and lower the expected display. The predicted categories are minimum height, maximum height, and maximum weight; Kyogre and Caterpie provide examples elsewhere in the FAQ. Testing requires an extraordinarily unlikely specimen at an exact endpoint, so these predictions remain unverified. The Pokédex also uses a different rounding convention from the measurement shown for an individual Pokémon, but it is not known whether that difference is intentional.

Other Unusual behavior not classified as a bug

Some surprising results are internally consistent with the documented model. XXL uses an unsquared height contribution during ordinary weight generation, so XL Pokémon can be heavier than XXL Pokémon. The Scatterbug family has a distinct XXS height range, and species use three different XXL upper bounds. Ordinary evolution between different XXL classes proportionally remaps height into the target range. These and other choices lead to confusing or "unnatural" results, but they seem to be intended game mechanics.

Thank you to the Silph Research Group for its pioneering work uncovering the mechanics behind much of the game’s original height and weight design.

Thank you to DrThod for extended discussions about statistical distributions and the tests needed to get to the bottom of the mysterious 0.01 kg Squirtle.

Thank you to an anonymous donor (you know who you are!) for providing extensive encounter data that made it possible to crack the original size-system mechanics, then the Pumpkaboo mechanics, and finally the new XXS/XXL system. Without those datasets, the inner workings of these systems would likely remain unknown even today.

Thank you to Riff, FlyFunner, 0ShadowNo1, mynameisjuan, Tobias, cy1110, and all the other members of the No Floats Left Research Group. Some of the formulas and edge cases described here would still be unknown, if not for all of your hard work!

Thank you to SellyMe for motivating me to build the original probability distribution tables and for their dedication to uncovering every bizarre anomaly in the Pokédex rounding mechanics.

Thank you to everyone I have left out who has been involved in uncovering the true mechanics underlying this game.