Linear Programming Calculator (Simplex Solver)

What linear programming does

Linear programming is the workhorse of operations research: a method for squeezing the best possible outcome out of a situation governed by limits.

You describe what you want in a single objective, to maximize profit or throughput, or to minimize cost, waste, or time, you list the decisions you control as variables, and you write down the constraints that hem those decisions in, whether machine hours, material, budget, or demand.

Every one of those relationships is linear, a weighted sum with no products or powers of the variables, and that linearity is exactly what makes the problem solvable quickly and reliably even when it has hundreds of variables. The result is the single combination of decisions that does best while breaking no rule.

The power of the method comes from a geometric fact. The constraints carve out a feasible region, the set of all decisions that satisfy every limit at once, and because both the region and the objective are linear, the best solution always sits at a corner of that region rather than somewhere in its interior.

That turns an infinite search into a finite one: examine the corners in an organized way and you will find the optimum. The simplex method, which this calculator implements, does exactly that, walking from corner to improving corner until none of the neighbors is better.

Along the way it produces not just the answer but the shadow prices, which tell you what each scarce resource is really worth at the margin.

This calculator solves any linear program you can type: choose maximize or minimize, enter the objective coefficients, and list the constraints one per line with a less-than, greater-than, or equality relation. It returns the optimal objective value, the value of every decision variable, whether each constraint is binding or has slack to spare, and the shadow price of each constraint. When your problem has exactly two variables it also draws the feasible region and marks the optimal corner, so you can see the geometry the algebra is describing. Everything runs in your browser, and nothing you enter is stored.

How this calculator works, step by step

Start by choosing the direction of the objective. Pick maximize when more is better, profit, units produced, contribution margin, and minimize when less is better, cost, scrap, or hours. Then enter the objective coefficients, one number per variable, separated by spaces or commas. The order you use here fixes the order of the variables everywhere else: if you type three coefficients, the tool expects three coefficients on every constraint line, in the same order. The calculator opens with a worked two-variable example already filled in, a classic product-mix problem, so you can see a correct solution and its graph before changing anything.

Next enter the constraints, one per line. Each line lists the coefficient of every variable, then the relational operator, then the right-hand-side value, for example “3 2 <= 18". You can use <=, >=, and = (the symbols and plain < or > work too). You do not need to add the non-negativity conditions that each variable is at least zero, because the calculator assumes them automatically, as standard linear programming does. As you type, the tool re-solves live, so the objective value, the variable values, and the constraint table update immediately, and the graph redraws for two-variable problems.

The result panel headlines the optimal objective value, then lists each decision variable with its optimal value. Below that, a table shows every constraint with how much of its limit the solution uses, whether it is binding or how much slack or surplus remains, and its shadow price.

A binding constraint is one the solution uses up completely; its shadow price is the improvement in the objective you would gain from one more unit of that resource. When the problem cannot be solved the tool says so plainly, reporting infeasible when the constraints contradict one another and unbounded when the objective can grow without limit.

Download a PDF or CSV of the solution or share it; all of it happens locally.

Walking the corners: how the solver works

The engine behind this calculator is the two-phase simplex method, the standard algorithm for linear programming. Its foundation is the theorem that an optimal solution, if one exists, is always found at a vertex, a corner, of the feasible region. Rather than test every corner blindly, the simplex method starts at one feasible corner and repeatedly steps to an adjacent corner that improves the objective, stopping when no neighbor is better, which by the theory guarantees the optimum. Each step is a pivot, a small algebraic operation that swaps one variable into the active set and another out, geometrically sliding along an edge of the region from one vertex to the next.

The two phases handle a practical wrinkle. When a problem has only less-than-or-equal constraints with non-negative right-hand sides, the origin is a convenient feasible starting corner. But greater-than-or-equal and equality constraints often exclude the origin, so there is no obvious place to begin.

Phase one solves an auxiliary problem that drives a set of temporary artificial variables to zero, which lands the algorithm on a genuine feasible corner; phase two then optimizes the real objective from there.

This calculator runs both phases automatically, so you can mix <=, >=, and = constraints freely and still get a correct answer, along with the detection of the infeasible case, when phase one cannot reach feasibility, and the unbounded case, when phase two can improve forever.

One reassurance about speed: although a region can have an enormous number of corners, the simplex method almost never visits more than a small multiple of the number of constraints before reaching the optimum, which is why it stays fast on the size of problem a person types here and on far larger industrial models. Each pivot also carries the running solution forward exactly, keeping the variable values and the shadow prices consistent at every step, so the figures the calculator finally reports are the exact optimum of the model you entered rather than a rounded approximation, apart from tiny values snapped to zero for readability.

Five worked examples you can follow

Example 1: the default product mix

The calculator opens maximizing 3x₁ + 5x₂ subject to x₁ ≤ 4, 2x₂ ≤ 12, and 3x₁ + 2x₂ ≤ 18. The optimum is x₁ = 2, x₂ = 6, giving an objective of 36. The second and third constraints are binding, used up completely, while the first has slack, since x₁ = 2 is below its limit of 4. The shadow prices are 0 for the first constraint, 1.5 for the second, and 1 for the third, meaning one more unit of the second resource would raise the objective by 1.5 and one more of the third by 1, while more of the first is worthless because it is not the bottleneck.

Example 2: reading the graph

Because that example has two variables, the calculator draws its feasible region as a polygon and marks the optimum at the corner (2, 6). Trace the edges and you can see why the answer sits there: the objective line, sloping by the 3-to-5 ratio of its coefficients, is pushed as far up and to the right as it can go while still touching the region, and it last touches at that corner. This is the geometric picture the simplex algebra computes, and seeing the two agree builds intuition for problems with more variables where the picture cannot be drawn.

Example 3: a minimization

Switch the objective to minimize and enter 2 3 with constraints x₁ + x₂ ≥ 10, x₁ ≤ 8, and x₂ ≤ 8. Now the goal is the cheapest way to meet a requirement of at least ten units combined. The optimum is x₁ = 8, x₂ = 2 with an objective of 22, since the first variable is cheaper per unit and is pushed to its limit before the more expensive second variable makes up the shortfall. The greater-than constraint is binding, and phase one of the simplex is what makes such a problem solvable, because the origin is not feasible here.

Example 4: a three-variable blend

Linear programming is not limited to two variables. Minimize 2 3 1 subject to x₁ + x₂ + x₃ ≥ 10 and x₁ + 2x₂ ≥ 8, a small blending problem. The optimum is x₁ = 0, x₂ = 4, x₃ = 6 with an objective of 18, because the third ingredient is the cheapest way to fill the first requirement while the second variable most cheaply covers the second. With three variables the calculator drops the graph, since the feasible region now lives in three dimensions, but the numeric solution and the shadow prices are computed exactly as before.

Example 5: an infeasible model

Enter a single variable with the two constraints x₁ ≥ 10 and x₁ ≤ 5. No value can be both at least ten and at most five, so the feasible region is empty and the calculator reports the problem as infeasible rather than returning a number. Seeing this is useful: an infeasible result almost always means a constraint was mistyped or the model is over-tight, and it is a prompt to re-examine the limits rather than a failure of the method. The companion case, an unbounded objective, appears when a maximization has no constraint stopping the objective from growing.

Three expert tips for a sound model

Shadow prices and the value of a scarce resource

The single most useful by-product of solving a linear program is the set of shadow prices, and understanding them turns the calculator from a solver into a planning tool. A shadow price is the rate at which the optimal objective would change if you had one more unit of a given constraint’s resource, holding everything else fixed. If a machine-hours constraint has a shadow price of 12, then one more machine hour would raise the optimal profit by 12, which is precisely the most you should be willing to pay for that extra hour. Shadow prices convert the abstract notion of a bottleneck into a concrete, per-unit dollar value, ranking your resources by how much releasing them is worth.

The pattern of shadow prices follows a simple and important rule. A binding constraint, one the optimal solution uses completely, generally has a non-zero shadow price, because relaxing it would let the objective improve. A non-binding constraint, one with slack or surplus left over, always has a shadow price of zero, because you already have more of that resource than the optimal plan can use, so an extra unit is worthless.

This is why the calculator marks each constraint’s status alongside its shadow price: the two together tell you not only where the money is being made but where adding capacity would and would not help. In the default example, the first constraint sits idle with a zero shadow price while the second and third, both binding, carry positive shadow prices, immediately identifying them as the bottlenecks worth attacking.

Reading the table this way is how experienced analysts decide where to invest, which supplier contract to expand, and which apparent limit is not really limiting anything at all.

The graphical method for two variables

When a linear program has just two variables the whole problem can be drawn on a plane, and the graphical method is the clearest way to build intuition for what the simplex algorithm does invisibly in higher dimensions. Each constraint becomes a line, and the inequality it carries keeps one side of that line; the overlap of all those half-planes, together with the non-negative quadrant, is the feasible region, a polygon. The objective function, meanwhile, is a family of parallel lines, one for each objective value, and optimizing means sliding that line as far as it will go in the improving direction while still touching the region. The last point it touches, always a corner, is the optimum.

This calculator draws exactly that picture for two-variable problems: it computes the polygon by intersecting the constraint boundaries, shades the feasible region, and marks the optimal vertex the simplex method found. Seeing the optimum land on a corner, and seeing which constraint edges meet there, makes the notion of binding constraints tangible, the edges that pass through the optimal corner are the binding ones, and their shadow prices are non-zero.

It also makes the pathological cases visual: an empty region means infeasible, and a region open in the improving direction means unbounded.

Although real problems usually have more than two variables and so cannot be drawn, the two-variable picture is the mental model that every linear programming practitioner carries into the higher-dimensional cases, where the same logic of corners, edges, and a sliding objective still holds even when it can no longer be seen.

Duality: every problem has a mirror image

Behind every linear program stands a second one, its dual, and the relationship between them is one of the deepest and most practical results in the field. Starting from the original problem, called the primal, the dual is formed by turning the constraints into variables and the variables into constraints.

If the primal maximizes profit subject to limited resources, its dual minimizes the total imputed value of those resources subject to the condition that the value assigned to the resources used by each product is at least the product’s profit.

The dual variables are, one for one, the shadow prices of the primal constraints, which is why the shadow prices the calculator reports carry a clean economic interpretation as the implicit value of each resource.

The central theorem, strong duality, says that when either problem has an optimal solution, so does the other, and their optimal objective values are exactly equal. The maximum profit the primal can earn equals the minimum resource value the dual assigns, a statement that the total worth of the scarce resources, priced at their shadow prices, accounts for all the profit.

This is not merely elegant; it is the basis of the economic reasoning that makes linear programming a decision tool rather than just an arithmetic exercise. Duality guarantees that the shadow prices are consistent, that they never over- or under-value the resources in aggregate, and it underlies sensitivity analysis, the study of how far the data can change before the optimal plan does.

Even though this calculator presents the primal solution and its shadow prices directly, those shadow prices are the optimal dual variables, so reading them is reading the answer to the mirror-image problem for free.

Where the modeling assumptions can bite

Linear programming rests on assumptions that are usually reasonable but occasionally break, and knowing them keeps a model honest.

The first is proportionality: the contribution of each variable to the objective and to every constraint is strictly proportional to its value, so doubling a variable doubles its effect, with no economies of scale, setup costs, or diminishing returns.

The second is additivity: the total effect is the sum of the individual effects, with no interaction terms where two products together use more or less than the sum of what each uses alone. The third is divisibility: variables may take fractional values, so the method can return 2.5 units, which is fine for tonnes of a blend but not for whole machines or people.

When divisibility fails, because the answer must be whole numbers, the problem becomes integer programming, which is genuinely harder and needs different algorithms; rounding a linear programming solution can give an answer that is infeasible or far from optimal, so it should be done with care and checked.

When proportionality or additivity fails, because of setup costs, price breaks, or interacting activities, the honest response is a more elaborate model, sometimes with binary variables or piecewise-linear approximations, rather than forcing a linear fit.

The certainty assumption, that all the coefficients are known exactly, is also worth remembering: real data is estimated, which is exactly why sensitivity analysis and shadow prices matter, since they show how sensitive the plan is to the numbers you are least sure of. This calculator solves the linear model faithfully; judging whether the linear model fits your situation is the analyst’s job, and these assumptions are the checklist for it.

Common mistakes to avoid

A handful of errors recur and quietly produce wrong or misleading answers. Watch for these.

• Misaligned coefficients. The coefficients on each constraint line must match the objective’s variable order exactly. A shifted column solves a different problem without any error message.
• Forgetting a constraint. An unbounded result usually means a real limit was left out. Every practical problem has something stopping the objective from growing forever.
• Rounding a fractional answer. If the variables must be whole numbers, rounding the linear solution can be infeasible or suboptimal. That is an integer program, not a linear one.
• Ignoring the shadow prices. The optimal mix alone does not tell you where to invest. The shadow prices rank the bottlenecks; skipping them wastes the most actionable output.
• Wrong optimization direction. Maximizing a cost or minimizing a profit gives a technically correct answer to the wrong question. Confirm the direction matches the goal.
• Over-tight equality constraints. Writing = where <= or >= was meant can make a solvable problem infeasible. Use equality only when the requirement truly must be met exactly.
• Treating estimates as exact. The coefficients are usually estimated, so a plan that is optimal for one set of numbers may not be for another. Check how sensitive the answer is before committing.

Where this model fits in the toolkit

Linear programming is the general optimization engine of operations research, and several of the other classic models are really special cases of it wearing different clothes. The Operations Research hub groups them together for that reason.

The transportation problem, shipping from sources to destinations at least cost, and the assignment problem, matching one set to another one-to-one, are both linear programs with a network structure so specific that faster dedicated algorithms exist for them; when your problem has that shape, those tools solve it more directly, but the answer they give is the same one the general simplex would.

When your problem does not fit a special structure, this general linear programming calculator is the right tool.

Beyond the optimization cluster, linear programming connects to the rest of the industrial engineering toolkit through the decisions it informs. The resource limits you enter as constraints often come from capacity studies, and the demand figures from forecasting; the plan it produces feeds scheduling and inventory decisions handled elsewhere on the network.

Decision analysis takes over when the future is uncertain and probabilities, not fixed constraints, drive the choice, and queuing theory answers the capacity questions that linear programming assumes as given. Seen this way, linear programming sits at the center of planning: it turns the limits established by other analyses into the single best plan, and its shadow prices point back to which of those limits is worth changing.

Return to the Operations Research hub for the full set of models.

A short history of the method

Linear programming as a general method dates to the 1940s, and its story is tied to both wartime logistics and postwar economics.

The decisive step was George Dantzig’s formulation of the simplex method in 1947, which gave the field a practical, general-purpose algorithm for the first time; earlier work by Leonid Kantorovich in the Soviet Union had posed similar optimization problems, and the two lines of thought, together with the economic interpretation developed by Tjalling Koopmans, shaped the discipline.

Kantorovich and Koopmans shared a Nobel Prize in economics in 1975 for that contribution, a rare recognition of an essentially mathematical technique’s impact on how resources are allocated.

The method spread quickly because it answered a universal question, how to do the most with limited means, and because the simplex algorithm proved remarkably fast in practice despite later theoretical results showing it could be slow on contrived worst cases. Those worst cases motivated the interior-point methods developed in the 1980s, which are provably efficient and are used alongside the simplex method in modern large-scale solvers.

For the size of problem a person types into a calculator, the simplex method this tool uses is both fast and transparent, producing not only the optimum but the shadow prices and the corner-by-corner logic that make linear programming an explanatory tool as much as a computational one.

That combination of a clear geometric idea, a practical algorithm, and a clean economic interpretation through duality is why linear programming remains, decades on, the first optimization method every operations research student learns.

From a business question to a solvable model

The hardest part of using this method is rarely the arithmetic, which the calculator handles; it is translating a messy real question into the three clean pieces the model needs. Start with the objective by asking what single quantity the decision is really trying to move, and in which direction.

If a plant manager says they want to run efficiently, press for the measurable stand-in, is it maximizing contribution margin, maximizing units shipped, or minimizing overtime cost, because the model optimizes exactly one thing and the choice changes the answer.

Resist folding several goals into one objective; if two aims genuinely compete, model the less important one as a constraint with a threshold rather than mixing both into the objective, which muddies the shadow prices.

Next name the decision variables, the levers the decision-maker actually controls.

These are usually quantities, how many of each product to make, how many hours to run each line, how much of each ingredient to blend, and it helps to write each one out in words with its unit before turning it into a symbol, because a variable whose unit is unclear tends to produce a constraint whose meaning is unclear too.

Then write the constraints by walking through every limit the decision faces: the resources that can run out, the demand that must be met, the ratios that must hold, the minimums a contract requires. Each becomes one line, and the coefficient of a variable on that line is simply how much of the resource one unit of that variable consumes.

A useful discipline is to check units on every constraint the way an engineer checks a formula: the left and right sides must measure the same thing, hours against available hours, kilograms against available kilograms. A constraint that mixes units is a modeling error the solver cannot catch, because to the algorithm it is just numbers.

Finally, sanity-check the solved plan against intuition before trusting it: if the optimum ignores a product you expected to make, or drives a variable to an implausible extreme, that is usually the model teaching you something, either a genuine insight or a sign that a constraint is missing or mis-scaled.

Reading the solution critically, not just accepting the number, is what turns the calculator from an answer machine into a thinking aid.

Input format and quick reference

Enter the objective as a row of coefficients, one per variable, separated by spaces or commas, and choose maximize or minimize above it. Enter each constraint on its own line as the variable coefficients in the same order, then the operator, then the right-hand-side value; use ≤, ≥, or = (plain <, >, and the words are accepted too). Variables are automatically taken to be non-negative. The reference below summarizes what each part of the result means.

Frequently asked questions

Sources, disclaimer, and editorial transparency

This calculator solves linear programs with the two-phase simplex method and reports shadow prices as the optimal dual variables, following standard operations research references (Dantzig’s simplex method; the primal-dual theory of linear programming). This calculator and guide are built and reviewed by the OpsCalculators team; see our Editorial Policy for how each tool is researched, built, and tested.

Results are accurate estimates for planning and education, not certified engineering advice, and the tool solves the continuous linear model; if your variables must be whole numbers the problem is an integer program and rounding may not be optimal. Validate against your own data before making commitments. See our full Disclaimer. OpsCalculators.com is operated by MAFHH INTERNATIONAL LTD. Your inputs are processed in your browser and are never stored; see our Privacy Policy.