iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Brute-force programming solves a problem by generating candidate answers systematically and testing each one, or comparing each one, against the requirement. It relies on checking possibilities rather than on a clever insight into the problem’s structure. That makes it simple to reason about and reliable when the candidate set is small, and impractical when the set grows explosively.
Two meanings of the term
In algorithm design, “brute force” usually means exhaustive search: list the possible solutions, then check them. The National Institute of Standards and Technology (NIST) algorithm dictionary defines the term as “An algorithm that inefficiently solves a problem, often by trying every one of a wide range of possible solutions.” The entry credits Paul E. Black as its author and was last modified on 2 December 2013.
In everyday programming talk, the phrase is sometimes used more loosely for any straightforward implementation that depends on raw computation instead of exploiting the problem’s structure. That usage is informal. The standard references cited here do not define it, so when you write or read about brute force, first establish which sense is meant. The rest of this article uses the algorithmic meaning.
How a brute-force program works
- Define the set of candidate answers the problem allows. For a route problem, this is every possible route; for a subset problem, every combination of items.
- Generate the candidates systematically, so that none is skipped and none is generated twice.
- Test each candidate for validity, or calculate its quality, such as total distance or total value.
- Keep a candidate that meets the requirement, or compare the candidates kept so far and retain the best one.
Where the program stops depends on the task. If any valid answer will do, the program can return as soon as it finds one. If the task requires the optimum or a list of all answers, it must continue through the full candidate space. A brute-force program does not always check every candidate; it checks every candidate only when the task demands that completeness.
Worked examples
Finding an item in an unsorted list
Inspect the elements one by one until the target is found or the list ends. Each element is a candidate, and the test is equality with the target. Because the list is unsorted, no shortcut is available, so in the worst case every element is examined.
The knapsack problem
Test each possible subset of items. Discard any subset whose total weight exceeds the capacity, then compare the total values of the subsets that remain and keep the highest. This example shows the two-step pattern common to many brute-force solutions: filter the candidates, then compare the survivors.
Route planning
Generate the possible routes through a set of stops, measure the distance of each, and keep the shortest. The idea is intuitive, which is why it is often the first approach people think of. The number of routes, however, grows very quickly with the number of stops, as the section on scale explains.
Naive string matching
Compare a pattern against the text at each possible starting position. A university teaching resource lists this as a practice example of brute force. The method is easy to verify, and it is the baseline that more efficient string-matching algorithms are usually compared against.
Rank #3
Why brute force becomes too slow
The main limitation is the size of the candidate space. The University of Texas at Austin’s 2026 teaching material describes n! candidate routes for a permutation search and 2^n subsets for a combination search. These counts apply to those search shapes; they are not a universal formula for every algorithm called brute force. OpenStax describes the broader problem as combinatorial explosion: candidate counts can grow so fast that exhaustive enumeration becomes impractical.
| Search shape | Number of candidates for n items | Typical example |
|---|---|---|
| Single pass over a collection | n | Finding an item in an unsorted list |
| Combination search (subsets) | 2^n, per the University of Texas at Austin’s 2026 teaching material | Knapsack |
| Permutation search (orderings) | n!, per the University of Texas at Austin’s 2026 teaching material | Route planning |
To make the difference concrete, with 20 items there are 1,048,576 subsets (2^20) but about 2.4 × 10^18 orderings (20!). Checking a billion candidates per second, the orderings alone would take roughly 77 years. The arithmetic is illustrative and assumes the stated search shapes.
Strengths and limits
- Clarity: the code follows the problem statement closely, which makes it easy to explain and to verify.
- Baseline: an exhaustive checker gives a reference answer for testing a faster algorithm.
- Guaranteed optimum: when the candidate set is finite and every candidate is generated and handled correctly, exhaustive search establishes the true best answer.
- Scaling: runtime depends on both the number of candidates and the cost of testing each one, so it becomes impractical as inputs grow.
Alternatives when the input grows
When candidate counts explode, look for structure that reduces repeated work or rules out candidates early. Three common families are:
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Clear out junk files and repair common Windows errorsFree Scan →- Divide and conquer splits a problem into smaller subproblems, solves them, and combines the results.
- Dynamic programming stores solutions to overlapping subproblems so that each is computed once.
- Greedy methods make a locally best choice at each step, but they are correct only for problems where that local choice provably leads to a global optimum.
No one of these dominates the others. The right choice depends on the problem and on the required output: one valid answer, the optimum, or all answers. Brute force remains useful in exactly the situations where its exhaustive guarantee matters more than speed.
Best Value
Brute-force password attacks are a separate application
“Brute-force password attack” applies the same candidate-testing idea to security. NIST’s glossary defines it as a method of accessing an obstructed device by trying multiple numeric or alphanumeric password combinations, and its cryptographic definitions describe trying all possible combinations of a key or password. This is a different topic from brute-force programming as a problem-solving method, and this article does not cover how such attacks are carried out. The programming sense concerns how candidate answers are generated and checked, not how systems are compromised.
Quick Recap
Deciding whether brute force fits
Use brute force when:
- the candidate space is small enough to enumerate within the time available;
- you need a correct reference answer to test a more efficient method against;
- the problem requires the true optimum and no structure can safely prune candidates.
Look for a different approach when:
- the candidate count grows as 2^n or n! and your inputs are large;
- the problem has overlapping subproblems or a provable greedy choice;
- a valid answer, not the best one, is enough, which may allow an early stop.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
