I feel like nobody gave a full technical explanation, so here goes.
To understand a chroot you first have to understand the split between kernel (The Linux in GNU/Linux) and userspace (the GNU in GNU/Linux, or possibly something else, like busybox.)
The kernel controls all the hardware in your computer. It also provides the APIs for file access, networking, and so on, and controls which software programs are running. This all forms an abstraction of the computer, which is presented through an application programming interface (API). It doesn't do anything at all on it's own though, except maybe boot up to a black screen. Not even a shell prompt.
The userspace is everything else. All the software that you run on your computer. Actually the kernel only runs one userspace program directly, init, which is then responsible for starting everything else, like shells and desktop environments. Userspace also includes libraries, which generally start with libc, upon which all the other libraries build.
So, with that in mind, the concept of a chroot is simple. It just changes the root directory of the unix filesystem to a different one, just for whatever command you choose to run in this context. This is usually a shell which you can launch other software, much as the kernel only launches a single command directly. This new context can have a different set of userspace programs and libraries. The same kernel is running both sets of software, so both systems can use all the hardware resources, but (barring security bugs) the nested chroot cannot access anything from the primary filesystem. It has it's own version of /etc for configuration, it's own /lib for libraries, and it's own /bin, /usr/bin for programs.
You should be aware that the hardware devices are shared. So, unlike a virtual machine, if you format /dev/sda from inside the chroot, you will format your real harddisk. This is because the device nodes in /dev are a direct kernel interface, therefore they mean the same thing inside and outside the chroot.
One other thing: it is possible to give the chroot access to the outer filesystem with bind mounts. If you use a chroot building tool it is possible that it "helpfully" mounts /home from the main system inside the chroot. This is not a copy, it's the same filesystem, and in this case any changes you make inside the chroot will be performed on the original. So I recommend you build chroots manually until you are comfortable with how they work.
Other than these two potential problems there isn't much that can go wrong with a chroot, as it is mostly a self-contained system that will only be started when you ask for it.