Officially, there is no such thing as "bytecode" (at least not in Java) -- it's simply "code". (You won't find "bytecode" anywhere in the Java Virtual Machine Specification.)
But informally it's the term applied to the virtual machine "instructions" in the "Code" attribute of a Java method definition inside a Java .class file. And the term is also applied (probably with no more "rigor") to the virtual machine instructions of several other languages such as C++.
The concept of virtual machine instructions is generally agreed to have originated with the "p-code" of UCSD Pascal and a few related early Pascal language implementations. Basically, these are a form of compiler "intermediate language" that can be interpreted directly by a "virtual machine", vs requiring an additional compile step to convert to native machine code. Typically, a virtual machine instruction set is designed to (as much as possible) be "machine independent" and not specific to any particular operating system or hardware instruction set.
Bytecode instructions are generally simple actions on a "stack architecture". The stack architecture is convenient because it's easy to compile to, allows "instructions" to be very simple, is easy to interpret, and is a convenient "source" for subsequent optimization and code generation steps in a regular compiler scenario. (A notable exception is the Android Dalvik virtual machine, with an instruction set that is not a stack archtecture, but rather a register-based architecture.)
In Java, it is most common for a Java program to be initially "interpreted", with the bytecodes being "executed" by the JVM's interpreter. Then, if and when individual methods are determined to be "hot" (highly used) the individual methods are compiled using a "just-in-time compiler" (JITC) into the instruction set of the "target" hardware. Other language implementations may stay wholly interpreted or may immediately translate to machine instructions.