How to Solve a System of Inequalities Graphically: Shading, Boundaries, and Test Points

To solve a system of inequalities graphically, graph every inequality on the same coordinate plane, shade the region each one allows, and take the overlap where all shadings coincide. That intersection is the solution set: every point in it satisfies all inequalities at once. Read a single point from the overlap only after confirming it sits on the correct side of every boundary line.

The shaded-region mechanism

A linear inequality in two variables, such as y > 2x − 1, describes a half-plane, not a line. The boundary line y = 2x − 1 splits the plane into two infinite halves, and the inequality sign selects which half counts. The strict symbol > excludes the line itself, so the boundary is dashed; ≥ includes it, so the boundary is solid. That distinction matters because a dashed boundary contributes no solution points at all, which is easy to miss when the shading looks generous.

The practical route is the test-point method. Graph the boundary as if the inequality were an equation, then substitute one convenient point that is not on the line, most often the origin (0, 0). If the substitution makes the inequality true, shade the side containing that point; if false, shade the opposite side. For y > 2x − 1, the origin gives 0 > −1, which is true, so the origin's side shades. This one check replaces guesswork about which way "greater than" leans, which reverses depending on whether the equation is solved for y or x.

The overlap is the system's answer, and its geometry follows from set intersection. Two nonparallel half-planes overlap in an unbounded wedge. Three can enclose a triangle, and four can form a quadrilateral. Each added inequality can only shrink the region or leave it unchanged, never enlarge it. That monotone behavior is why systems are described as feasible-region problems: you are carving a permitted zone out of the plane one constraint at a time.

For nonlinear inequalities, graph the curve (a parabola for y ≥ x² − 4, a circle for x² + y² < 9), then test a point. A circle inequality shades the interior or exterior, and a parabola shades above or below the curve. Treat every curved boundary exactly like a line boundary: solid for inclusive symbols, dashed for strict ones, test point to pick the side.

Quantified context: bounds, vertices, and feasible regions

Graphing becomes decision-relevant when coordinates carry units. Suppose a workshop builds tables and chairs, with x tables and y chairs per week. Labor caps production at 2x + 3y ≤ 60 hours, storage caps total units at x + y ≤ 25, and each variable must be nonnegative. Each inequality is a half-plane in the first quadrant, and the four together yield a bounded quadrilateral. Its corners are (0, 0), (25, 0), (15, 10), and (0, 20). The corner (15, 10) is the special one: it satisfies both 2(15) + 3(10) = 60 and 15 + 10 = 25 exactly, so both constraints are tight there.

Vertices like that are the reason graphing pairs naturally with linear programming. If profit is USD 40 per table and USD 25 per chair, evaluating the objective 40x + 25y at each corner gives USD 0, USD 1,000, USD 850, and USD 500. The best corner is (25, 0), at USD 1,000. The maximum of a linear objective over a bounded feasible region always occurs at a vertex, so checking corners is not a shortcut but a theorem-backed method. Graph the feasible region to see it; test the corners to optimize over it.

The unbounded case behaves differently. A system like y ≥ x + 2 and y ≤ −x + 6 overlaps in an infinite wedge opening upward, with corner (2, 4). If an objective improves without limit inside that wedge, the problem has no finite maximum and is called unbounded. A graph makes this obvious because the shaded overlap visibly escapes the frame, while a purely algebraic check can miss it.

Boundary inclusion deserves a count. A region bounded by four lines with all-inclusive symbols has four boundary segments and four vertices; switch one symbol to strict and you delete one entire edge from the solution set while keeping its endpoints in limbo. Small symbol changes produce large feasibility changes. That is why every graph should carry explicit dashed or solid notation, not just shading.

Edge cases that break casual graphs

Parallel boundaries create the most common surprise. If a system contains y > x + 1 and y < x + 4, the overlap is a diagonal strip one unit wide, infinite in both directions, with no vertices at all. Same-side inequalities such as y > x + 1 and y > x + 4 reduce to the stronger constraint alone: the lower requirement is redundant, because any point above y = x + 4 automatically clears y = x + 1. Before graphing, scan for parallel pairs and same-direction slopes; resolving them algebraically saves drawing effort and prevents phantom corners.

No overlap means no solution. The pair y > x + 2 and y < x − 3 describes parallel lines five units apart with shading fleeing from each other, so the intersection is empty. The feasible region is the empty set, and no test point exists. Reporting "no solution" is a legitimate, common answer in systems work, not a failure of the method.

Division and multiplication by negatives flip inequalities, and the flip propagates into the graph. Rewriting −2y < 6 as y > −3 changes which side of the horizontal line y = −3 shades. A teammate who solves for y without flipping produces a mirrored, wrong half-plane that still looks plausible on paper. Check that boundary line's shading against a test point every time you manipulate a symbol.

Strict inequality boundaries carry another caveat: the solution set is open along the excluded line. A vertex formed where two dashed lines cross belongs to neither boundary, so a corner that looks included in the shaded triangle is actually outside the solution set. This rarely changes an answer, but it matters in optimization when two constraints are tight at once. The best corner may sit on a dashed line, and whether that corner itself counts as feasible depends on the symbols.

Misconceptions worth correcting

The most persistent misconception is that each inequality shades its own side and the solution is a single shaded region rather than the intersection. Graph paper with one shading color per line, marked I, II, III, makes the overlap legible. Counting how many shadings cover each area converts the picture into a truth table: an area covered by all three is the answer.

A second misconception treats boundary lines as solutions. A line contributes points only under an inclusive symbol, and only as the edge of the shaded half. For y ≤ 2x + 3, the line y = 2x + 3 is a wall belonging to the rooms on one side, so the line and the region below it are both included. For y < 2x + 3, the wall is gone and only the open region remains.

A third misconception holds that three inequalities guarantee a triangle. Three half-planes can also overlap in a wedge, a strip, or nothing, depending on slopes. A triangle requires three lines forming a genuine triangle with shading directed inward, which is a property of the specific signs, not the count. Always draw and verify rather than assuming the shape.

A counterintuitive professional caveat: the graphical picture certifies qualitative structure, not numeric correctness. A slope drawn slightly off shifts every vertex, and an optimization answer read from a misplaced corner can be wrong by whole units even though the drawing "shows" a triangle. Certification requires substituting each claimed vertex back into all constraints and checking the objective algebraically. Use the graph to find structure, use algebra to confirm it, and trust the graph's shape only after the corner coordinates check out.

Comparison of solution methods

The honest comparison: no method dominates. Graphs answer "where is the region," algebra answers "what exactly are its vertices," and corner testing answers "which vertex wins." A defensible workflow uses all three on any problem that matters.

Timeline of a reliable graph

Fourteen minutes buys a graph you can defend. Skipping step 5 is the hallmark of thin explanations and the source of most wrong corner answers.

Practical actions and thresholds

Rewrite every inequality with the variable on the left before graphing; if you divide or multiply by a negative number, flip the symbol immediately and re-read the sign. Draw dashed boundaries for strict symbols (<, >) and solid lines for inclusive symbols (≤, ≥); decide by symbol, not by habit. Use (0, 0) as the default test point, but pick (1, 1) or another off-line point when the origin sits on a boundary. Resolve parallel and same-direction inequalities algebraically before drawing; redundant constraints waste effort and fake corner points. When an objective exists, list every vertex coordinate and substitute it back into all constraints before computing the objective value. Red flags: shading each inequality on a separate sheet and calling the union the answer; a shaded region with no labeled boundary symbols; a corner reported without substitution; a bounded-looking picture for a system that is actually unbounded.

Reconciling thresholds across sources is simpler than it sounds. Symbol rules, test-point rules, and vertex rules never conflict because they answer different questions. Strict versus inclusive decides line type; the test point decides direction; substitution decides whether a corner is real. When an old worksheet and a new textbook disagree about marking the boundary, the disagreement is almost always notation, not mathematics. Adopt one convention (dashed equals excluded) and apply it without exception.

Limitations and what graphs cannot promise

Graphing answers existence and structure, not precision. With two variables, a photograph of the feasible region is adequate; with three, you need planes in space, and beyond three variables humans simply cannot draw the region. That is a hard limit of the method, not a skill issue. Algebra and software take over as dimensions grow, and the graphical intuition survives as a mental model rather than a computation.

Nonlinear systems compound the imprecision. Curves can intersect at irrational coordinates, and a hand-drawn vertex may be off by enough to spoil a corner test. When exactness matters, the graph should be paired with substitution that produces algebraic corner values. If those values cannot be produced by hand, technology is the honest tool, and its output still needs a sanity check against the shaded picture.

Finally, interpretation errors outnumber computational errors. Students and reviewers report "no solution" when they meant "I did not shade carefully," and they report a triangle when a dashed edge excludes it. The graph is a claim about a set, and a claim needs the same discipline as an equation: state the set, show the overlap, verify the corners. Claims built that way survive review.