Ans : 

Something is mangling the .class file. Most likely the .class files were uploaded to the server as text or MacBinary rather than as raw binary data. Make sure you put your ftp program in binary mode before sending the files to the server.
The other possibility is that the web server is sending the file to clients as text rather than binary data. Make sure the web server is configured to send files that end in ".class" with a MIME type of application/octet-stream. Many web servers send files as type text/plain which often works but causes problems on a few servers. In particular, WebStar needs to change the action to "binary" and the MIME type to "application/octet-stream". 

It's also possible on some platforms that Netscape just can't find the .class file; that is, it isn't in the directory where Netscape is looking for it. Technically, this isn't really a ClassFormatError, but this is how Netscape reports it on some platforms and versions. 

Ans : 

This is almost always means Netscape can't find one of the classes it needs to run the applet. Check to make sure that the classes your program uses are in the CODEBASE, the CLASSPATH, or somewhere else Netscape can find them. It's not uncommon to get this error when you first test a new package or class you've written with Netscape. If you've only tested it with the applet viewer or an IDE, then the applet viewer or the IDE may have included the current directory in the CLASSPATH where Netscape does not. Therefore the applet viewer can find the right class, but Netscape can't. Explicitly add the path containing your class or package to the CLASSPATH as specified in the previous question. 

Ans : 

It could be one of several reasons, and unfortunately the messages that you get in this situation aren't much help. In general, you can assume that either your applet's class files are corrupted somehow, or
the web server can't find one or more of them when the browser needs them.
Be careful of the following things:
o Make sure you transfer the class files in binary mode, rather than text or ASCII mode. An error from the browser saying "cannot start applet ... bad magic number" usually means that one of the class
files on the server is corrupted. Replace your class binary files on the web server, clean up the cache of your browser, and reload your applet.
o Make sure you transfer all of the class files that are a part of your applet. Sometimes people are surprised by how many there are. There will be a class file for every class and interface you
define, even if you define more than one in a single source file. If you use the Java 1.1 "inner classes" feature, there will be class files for each inner class as well.
o Make sure you maintain the appropriate case distinctions in your filenames. If a class is called StUdLy, it must be found in a file called StUdLy.class.
o Make sure you maintain the directory structure that matches your package structure. If you declare a class in package com.foo.util, the class either needs to be in a Jar file, or the class file needs to be in directory com/foo/util under the applet's codebase directory. Again, case distinctions are important for
package/directory names, just as they are for class/file names.
o Make sure that the web server process will have read access to the class files, and search access to the directories that the files are in. For example, if the web server runs on a Unix machine, use the command "chmod o+r filename" for the files, and "chmod o+x dirname" for the directories.

Ans : 

This is a security feature that prevents the applet programmer from popping up a window that

looks like it came from the native OS and asking for passwords or credit card info (etc.). 

Users must always be aware of when they are talking to an unsigned applet. You can get rid
of it by signing the applet, if the user accepts signed applets from you. 

In Netscape (only), using the Capabilities API to make the call

        PrivilegeManager.enablePrivilege("UniversalTopLevelWindow");

before creating the Frame eliminates the message, if the security manager passes it.

Ans : 

Are you behind a proxy server or firewall? If so, one of the servers between you and the Internet may be excluding the .class files (or the archive .jar, .cab, or .zip files) that the applets need to run (actually, they ARE the applets). 
You may need to contact the sys admin and ask whether .class files are allowed through. 

Can you try to download an applet and view it locally? 
If you get the same error, then the problem is with your computer or browser, not the network. 

Ans : 

This is one of the more opaque and uninformative error messages!

For a full definition of magic number, see the jargon dictionary.

However, the cause for this error almost never has anything to do with what a magic number is.

The error is caused when .class files are transferred as ascii text files instead of binary files.

This problem is particularly common for people using ftp clients which are set to automatically detect file type.

Just make sure your .class files are uploaded and downloaded as binary, not ascii.