Allow an object to alter its behavior when its internal state changes. The object will appear to change its class.
The State pattern structure is similar to the Strategy pattern structure. Here are their structure diagrams from GHJV, along with their intents.
Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it.
Allow an object to alter its behavior when its internal state changes. The object will appear to change its class.
What are the differences here? There are two, neither of which is conspicuous in the diagrams.
In the Strategy pattern, methods of the Context class use the Strategy methods in their implementation, but the Strategy methods are not directly visible to Context clients.
In the State pattern, methods of the Context class are directly delegated to the State classes.
In the Strategy Pattern, clients of a Context object set the State object that it references. This is usually set once, often as a Context constructor parameter.
In the State pattern, the State and/or Context classes determine the State object that is referenced by a Context object. This determination is made dynamically.
Both differences concern the relationship with the Context client, which does not appear in either diagram. The latter difference is intimately related to the intents of the patterns so it is the more fundamental difference.
The Strategy and State patterns are patterns for delegation with different intents. In real-world design intents do not always fall into clear-cut bins. It is likely that some design problems are best solved by using delegation in a way that allows all participants to have some say about the delegator-delegatee relationship.
Delegation is a common theme in behavioral design patterns. The Observer and Chain of Responsibility patterns are two more examples.