Do two segments intersect?

This segment intersection checker answers a classic plane-geometry question: given two closed line segments by their four endpoints, do they cross or touch, and if so where? When a solution exists it returns intersects true, the kind of contact (proper crossing, endpoint touch, or collinear overlap), the coordinates of a shared point, and the parameters t and u. Missing or non-numeric endpoints fail immediately with invalid_input so failed validation is never charged.

What segment intersection means and how it differs from infinite lines

Search intent clusters around phrases such as do two segments intersect, segment intersection calculator, line segment cross check, and find intersection of two segments from coordinates. That intent is deliberately different from an infinite-line solver: extending both segments as full lines can invent a crossing far outside the finite edges that matter for polygons, collision bounds, and map links. In Euclidean plane geometry a line segment is the closed set of points between two endpoints, not the infinite line that extends through them. Two segments intersect when they share at least one common point: they may cross in their relative interiors (a proper intersection), meet only at an endpoint (a T-junction or shared vertex), or lie on the same supporting line and overlap on a subsegment or a single point (collinear contact). Students want a numeric yes-or-no with coordinates against a homework key; developers want a deterministic oracle for edge–edge tests in meshes, UI hit regions, and contest validators; survey and CAD assistants want structured JSON they can paste into reports without reimplementing orientation or Cramer arithmetic in every language. Delivering intersects, kind, and optional point fields as JSON makes the result easy to assert in continuous integration, feed into a larger pipeline, or copy into notes. The calculator treats segments as closed, so endpoint-to-endpoint contact counts as an intersection rather than a silent miss, which matches the usual closed-segment convention in computational geometry textbooks and school problems.

How endpoints are validated and how the intersection is computed

Computation uses the standard parametric form: write P equals A plus t times (B minus A) and also P equals C plus u times (D minus C), form the two-by-two system whose determinant is the two-dimensional cross product of the direction vectors, and solve for t and u. There is no third segment, no least-squares fit, and no unit conversion of the coordinates themselves; the arithmetic assumes a shared Cartesian frame. Send a JSON body with the eight required fields x1, y1, x2, y2, x3, y3, x4, and y4. Each field must be a finite number; JSON numbers and plain decimal strings are accepted, and short aliases such as ax, ay, bx, by, cx, cy, dx, and dy map onto the same coordinates. The engine rejects missing fields, empty strings, NaN, and infinities with invalid_input so those failed calls are not charged and never invent a fake crossing. When the determinant is safely nonzero and both parameters land in the closed unit interval, the segments meet at that P; endpoint contact is flagged when a parameter sits at zero or one. When the determinant vanishes the supporting lines are parallel: if the endpoints are not collinear there is no intersection; if they are collinear the engine checks whether any endpoint of one segment lies on the other and, when they overlap, reports intersects true with one representative shared point rather than an interval of solutions.

Where segment intersection checks fit in study, design, and code

A textbook may give four endpoints and ask whether the segments cross, or present a figure where only an infinite-line extension would meet; this checker returns a clear boolean plus coordinates when contact exists and kind none when it does not. Teachers can pre-generate answer keys that list intersects and the point for mixed proper, endpoint, and parallel cases, and rely on invalid_input for incomplete rows instead of printing a blank or a silent Infinity. 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 classroom demo to an automated pipeline without changing the mathematical result.