Javaクラスファイルの構造は以下の構造体定義で示すことができます。

 ClassFile {
         u4 magic;
         u2 minor_version;
         u2 major_version;
         u2 constant_pool_count;
         cp_info constant_pool[constant_pool_count-1];
         u2 access_flags;
         u2 this_class;
         u2 super_class;
         u2 interfaces_count;
         u2 interfaces[interfaces_count];
         u2 fields_count;
         field_info fields[fields_count];
         u2 methods_count;
         method_info methods[methods_count];
         u2 attributes_count;
         attribute_info attributes[attributes_count];
     } 

マジックナンバー

ClassFile構造体の先頭はマジックナンバーです．その値は16進でCAFEBABE と決まっています．先頭がCAFE BABEでないファイルはベリファイをパスしません。

バージョン

次の項目はこのクラスファイルを作成したバイトコード・コンパイラのバージョンです．バージョン番号がJavaVMのサポートしていないものだった場合は，それを実行することは許されていません．

コンスタントプール

コンスタントプールは定数やクラス名などを保持するためのものです．
コンスタントプールは可変長の要素を持つ，0～ConstantPoolCount-1までの一種の配列ですが，クラスファイルには0番目の要素は含まれていません．0 番のエントリはJavaVM内部用に予約されており，クラスファイルで使用することはできません．同時に0番は無効なインデックスであり，これを使用するクラスファイルはベリファイをパスしません．
コンスタントプールは配列として表現されてはいますが，要素が可変長であるため，添字から各エントリへ単純にアクセスすることはできません．  

アクセスフラグ

このクラスの修飾子に対応するフラグです．access_flagsの各ビットが public,final,interface,abstractの各修飾子に対応しています．finalと abstract，finalとinterfaceのように，同時にセットすることが許されていないフラグもあり，もしそれらが同時にセットされているとベリファイをパスしません．
通常の修飾子とは異なるsuperというフラグもありますが，これは古いコンパイラとの互換性を保つためのものです．新しいコンパイラでは常にセットされていなければなりません．
現在のバージョンで使われていないビットもありますが，それらは将来に備えて予約されており，現在は常に0にしなければなりません．これはフィールド情報やメソッド情報にあるアクセスフラグでも同様です．

thisクラス

this_classはこのクラス自身を表しています．これはコンスタントプールへのインデックスになっており，コンスタントプール中の該当するエントリはこのクラスへの参照を表すCONSTANT_Class_infoになっています．

スーパークラス 
super_classは直接のスーパークラスを表しています．直接のスーパークラスを持たないクラス（即ちjava.lang.Object）やインターフェースの場合は，この数値は0になります．それ以外の場合はthis_classと同様です． 

スーパーインターフェース 
interfaces[]は直接のスーパーインターフェースを表します．スーパークラスとは異なり，直接のスーパーインターフェースは複数持つ可能性があるので配列になっています．直接のスーパーインターフェースを持たない場合は interface_countが0になり，配列そのものがなくなります．それ以外は this_classやsuper_classと同様です．
図4の例では，this_classが2，super_classが1になっています．これより順に辿ると，このクラスの名前はGalaxyで，そのスーパークラスの名前は Sovereignであることが分かります． 

フィールド情報

fields[]はfield_info構造体の配列で，このクラスで定義しているフィールドに関する情報を保持しています．

access_flagsの各ビットは，このフィールドの修飾子に対応しています． publicとprivate，finalとvolatileなどを同時にセットするとベリファイをパスしません．また，このクラスファイルがインターフェースを表していた場合， finalとstaticがセットされていないとベリファイをパスしません．
name_indexで指定されるCONSTANT_Utf8_infoはフィールド名として有効な文字の並びを保持していなくてはなりません．そうでなければベリファイをパスしません．descriptor_indexについても同様です．
コンスタントプール回りの例が図4にあります．もう見れば分かると思いますが，fields[0]がint型のNcc，fields[1]がint型のMiranda，fields[2]が iveLongAndProsper型のYouWillBeAssimilatedというフィールドを，それぞれ表しています．  

メソッド情報

methods[]はmethod_info構造体の配列になっており，このクラスで定義されているメソッドに関する情報を保持しています．method_info 構造体は形式だけならばfield_info構造体と同じですが，ディスクリプタやアクセスフラグの詳細などが異なっています．

access_flagsの各ビットは，このメソッドの修飾子に対応しています． publicとprotected，abstractとfinalなど，同時に使用できないフラグもあります．それらが同時にセットされていた場合は，ベリファイをパスしません．  

属性

属性とは，今まで紹介された以外の様々な情報を保持するものです． ClassFile構造体の他，field_info構造体，method_info構造体，そして属性であるCode_attribute構造体の中で使われます．属性には仕様書で定義されている定義済み属性と，新たにユーザーが定義する属性とに分けられます．
属性の基本フォーマットとなるattribute_info構造体を図8に示します．全ての属性はこのフォーマットに従わなければなりません．逆に言えばこのフォーマットに従っており，且つ定義済み属性で予約されていない有効な名前を持つ属性ならば，新たに定義することはユーザーの自由です．

当然のことながら，ユーザーによって新たに定義された属性の中には JavaVMが認識できないものも出てきます．このため，認識できない属性を単純に読み飛ばすことはJavaVMに必須の機能になっています． 

 
定義済み属性
JavaVM仕様書で定義されている定義済み属性の一覧を下記の表に示します．このうち，JavaVMが必ず認識しなければならない属性はCode属性，ConstantValue 属性，Exceptions属性，InnerClasses属性，Synthetic 属性の５つです．それ以外の属性については必ずしも認識する必要はありません．(もちろん認識した方がより良いのですが．)
表3：定義済み属性一覧