My TL;DR Definition:

Encapsulate each algorithm in a set such that they are interchangeable with each other.

Slightly Longer Definition:

The strategy pattern is used when a group of algorithms (or behaviors) ought to be encapsulated in order to be interchangeable with each other. This way a client (or an implementation of a class) can be composed with these algorithms rather than be tightly coupled with a certain particular algorithm. Plug and play!

Typical Animal OOP Example:

Suppose we were to create an Animal class and we know that all animals have a certain behavior of making a noise. Most animals make different noises from each other but sometimes we will have multiple instances of the same kind of animal or animals that are of different breeds but not "type" and furthermore there could be animals that don't make any noise at all. Instead of having a concrete implementation of a makeNoise behavior for each animal type, we can delegate this behavior to an interface and define an implementation of that interface elsewhere.

Pseudocode

//before Strategy Pattern
public class Animal
{
	makeNoise()
	{
		...
	}
}

public class Snail extends Animal {
	makeNoise()
	{
		//overriden to make no noise
	}
	//oh boy, we're gonna have to do this for EVERY
	//type of animal! What a headache...
}

//AFTER Strategy Pattern
interface INoiseBehavior
{
	void makeNoise();
}

class Bark : INoiseBehavior
{
	void INoiseBehavior.makeNoise()
	{
		//play bark.ogg
	}
}

class NoNoise : INoiseBehavior
{
	void INoiseBehavior.makeNoise()
	{
		//play nothing
	}
}

public class Animal
{
	INoiseBehavior noiseBehavior;

	public void executeNoise()
	{
		noiseBehavior.makeNoise();
	}
}

public class Dog extends Animal
{
	public Dog()
	{
		noiseBehavior = new Bark();
	}
}

public class Snail extends Animal
{
	public Snail()
	{
		noiseBehavior = new NoNoise();
	}
}
//wow so much easier to COMPOSE these classes!
//thanks Strategy Design!

So while it looks like a lot more code, design strategy allows us to swap out behaviors very easily when implementing new classes. This is important since requirements of our code changes and changes often. We encapsulated the parts that vary without touching the parts that won't. Neat!