Carry-on size checker

Non-positive dimensions are rejected with invalid_input because a zero or negative edge is not a physical bag measurement.

What a carry-on fit check means and what the response contains

Airlines publish a maximum rectangular volume for cabin bags, usually as three exterior dimensions that must fit inside a rigid or semi-rigid sizer at the gate or counter. Travelers care about a yes-or-no answer plus a little diagnostic detail: which edge is tight, whether rotating the bag helps, and whether the linear sum of length plus width plus height still sits under a published linear limit. This checker answers that planning question with transparent geometry. When rotation is disabled, length is compared to max length, width to max width, and height to max height exactly as supplied, which matches labels printed on some hard-shell cases. When allow_rotation is true, the default, both the bag triple and the airline triple are sorted from smallest edge to largest edge, then each ordered bag edge is compared with the matching ordered limit; the bag fits only if every bag edge is less than or equal to its partner. That models free reorientation inside a rectangular sizer without inventing diagonal or soft-compression tricks. The response includes a boolean fits flag, a status token of fits or does_not_fit, a human-readable status_label, the unit label you passed, the allow_rotation flag used, bag and max objects with each edge and the linear sum, an axes array with bag, max, fits, and slack for each ordered axis, fits_linear and linear_slack for the L plus W plus H rule, a method tag carry_on_check, a formula string for audits, and a short note that wheels and handles can still fail a physical gauge. There is no live airline database and no random sampling: the engine either builds a finite comparison inside the supported range or rejects the input with invalid_input. Rejected cases include missing edges, non-finite values, magnitudes above the documented ceiling, and any non-positive bag or allowance dimension, because zero and negative lengths are not valid exterior sizes.

How bag and airline dimensions are read and how results stay reproducible

Optional unit is only a label—default centimetres—and never converts numbers; you must already express bag and limits in one unit. Optional leading plus signs and scientific notation on numeric strings are allowed when they parse as finite decimals; embedded spaces, hex prefixes, and non-numeric tokens are rejected with a clear message so a bad cell does not become a wrong fit decision. Slack on each ordered axis is max edge minus bag edge, so negative slack means that axis alone would fail. Linear sum is the sum of the three raw bag edges compared with the sum of the three raw max edges without reordering, because published linear limits are usually stated on the unordered exterior measurements. The preferred bag fields are bag_length, bag_width, and bag_height, with aliases such as length, width, height, depth, L, W, and H so spreadsheets and typed forms can reuse the same contract. Airline limits use max_length, max_width, and max_height, with aliases like airline_length, limit_width, and allowance_height. Optional allow_rotation accepts boolean true or false and common string forms; it defaults to true so typical soft bags get the sorted comparison. All six required edges must be strictly greater than zero: a zero height or a negative width fails with invalid_input and is not charged through the API path. Pair the free browser run on this page with the priced API when you need the identical geometric result inside an automated pipeline without re-implementing sorted pairwise checks yourself.

Where carry-on checks fit in packing, teams, and software

On this page the work runs entirely in your browser; through the API each successful lookup costs $0.002, failed validation is not charged, and nothing is stored after the response returns. That split—free interactive exploration and a priced, identical API—matches the rest of the KIT tier-A catalog and lets you move from a packing demo to an automated pipeline without changing the geometric result.