Other answers have focused on what is client-side and server-side programming: what languages are mostly used, what tasks have to be accomplished, etc.
This is absolutely right, but I miss a bit of focus on what are the differences between both types of programming, in the context of web programming. Let me try to address that.
Security and permissions
In server-side programming, it is good practice to also limit the access of each application to the underlying system, but this is much less enforced on you, since in the end, you or your company are in control of that system. This 'isolated cage' design is not built-in into the server-side programming tools and languages, but is accomplished through installation setup (using dedicated users with restricted permissions, choosing ports that require or do not require root permissions, etc).
Deployment and platform
In server-side programming, deployment has to happen from outside your code, using some kind of tool (even if it is
make install or a
git clone), and this deployment is usually manual — or at least, it is expected to happen in a semi-supervised way. The system (meaning the OS) on which you deploy is usually uniform across a number of machines, but it can be heavily customized to your needs.
In client-side programming, deployment happens from your server-side code, which serves the clients automatically and without supervision. The underlying system (meaning mainly the browser) can be very different across a much larger number of machines. In order to make deployment feasible at all, standards have to be kept, and there is a much stronger trend to a single language and environment.
This is why copying server-side code from one machine to another can take weeks, while client-side code is usually trivial to execute in different machines.
State and secondary effects
(Disclaimer: this is by far the most subjective point of all. Probably there are many wrong aspects to my argumentation. It is just an interesting hypothesis, in my view. )
In server-side programming, state is a much bigger concern, meaning how to retrieve and update data at the request of the user with the possibility of conflicts due to concurrency. Even if most of this complexity is offloaded to a database server, it is the server-side code's responsibility to allow the database to keep its guarantees on data integrity by using its interface correctly (e.g. not use a cache for updates that are never seen by the DB), while it is also a goal of the server-side code not to overload the database with work and keep the user waiting for response.
In client-side programming, presenting the results to the user is a much bigger concern, and this implies secondary effects (mostly printing to the screen). This is not to say that there is no state involved (e.g. cookies), only that the main goal of the code is to actually interface with the user, and this cannot happen without secondary effects.
This is why client-side programming usually requires (at some point) looking at the screen with a demo, to check that all colors and layout are right, while server-side programming can happen almost exclusively in a text-oriented environment, where automated tests check that the logic is still doing what it is supposed to do.