Class Diagrams and Object Diagrams use almost identical notations.  Both represent a static view of a system, however Object Diagrams represent a snapshot in time, whereas Class Diagrams are not time dependent and are an abstract view of the types of objects that may exist within a system, the relationships between them, and how and when one type of object can exist in relationship to another.  Since Object Diagrams represent specific object instances that exist at a single point in time, they are sometimes called Instance Diagrams.

A few notable differences in the notation and rules used to represent Class and Object Diagrams are:

1. Class Diagrams represent each class via a rectangle and display up to 3 types of information; the class name (not underlined), its attributes, and its operations.  The Object Diagram also uses a rectangle to represent an object instance, however the object name is underlined and lists the name of the object followed by a colon and then the class name which describes its type (e.g.  Joe: Student, where Joe is the name of the object instance and Student is class).   Additionally the Object Diagram will list an object's attributes, but it will also list the value of that attribute at that point in time (e.g. SSN = 555-55-5555).
2. Class Diagrams enforce multiplicity rules between associated classes.   For example, a Class Diagram may display an association between a Car and Passengers.  The Class Diagram would show a single rectangle to represent the class car and a single rectangle to represent the class passenger, but display multiplicities stating that each car may have 1..4 passengers.  An Object Diagram being a snapshot in time would show a rectangle for the Car and up to 4 separate rectangles, one for each passenger that exists at that movement in time.
3. Many of the constraints or association types that exist in a class diagram have no relevance in an object diagram.  Multiplicities in a class diagram may constrain the number of passengers in a car to 4, but this rule would be enforced within the code itself such that a 5th passenger object could never be created.  Therefore, multiplicities are not shown within an object diagram.  Only the actual numbers of objects that exist at that moment in time are shown.  Similarly, other constraints such as "at least one passenger be of type driver" could also be captured and displayed in a class diagram but would not be shown in an object diagram since these rules are enforced within the actual code.