Automatic Resource Management

Scanner is Closable, so you can use the automatic resources:

try (Scanner content = new Scanner(new File(fileName))) {
    ... rest of code goes here, don't need a content.close();
}

Menus

There are lots of options for implementing menus. Using arrays and referring to indexes to determine which menu they go under and to find out which menu was chosen works okay for small applications, but doesn't scale and requires multiple places to change index references when you decide to reorganize the menus.

If you use subclasses of javax.swing.AbstractAction, you can keep the logic for the actions separate. Also, later on, you could add the same action to both a menu item and a toolbar. See the Action javadoc for properties you can put into an action. You can create a subclass of AbstractAction with multiple constructors and helper methods for setting and getting description, icon, mnemonic, etc.

Comments

You don't need to begin JavaDoc comments with "This class ..." or "This method ...". See the Method descriptions begin with a verb phrase section.

Some boilerplate does not need comments. For example, the "imports" section does not really need a comment. Also, some comments describe a little too much what is going on, and not the why (e.g. instead of "Sets formatting to break line at whole words ...", you could just have one comment "Create and format the JTextArea", unless there's a line you think will be particularly likely to forget why it's there.

Not a big issue, but plurals in English don't use apostrophe (e.g. menu's can be menus).

Automatic Resource Management

Scanner is Closable, so you can use the automatic resources:

try (Scanner content = new Scanner(new File(fileName))) {
    ... rest of code goes here, don't need a content.close();
} catch (FileNotFoundException fnfe) {
    System.out.println("This error was thrown: " + fnfe);
}

Menus

There are lots of options for implementing menus. Using arrays and referring to indexes to determine which menu they go under and to find out which menu was chosen works okay for small applications, but doesn't scale and requires multiple places to change index references when you decide to reorganize the menus.

If you use subclasses of javax.swing.AbstractAction, you can keep the logic for the actions separate. Also, later on, you could add the same action to both a menu item and a toolbar. See the Action javadoc for properties you can put into an action. You can create a subclass of AbstractAction with multiple constructors and helper methods for setting and getting description, icon, mnemonic, etc.

Comments

You don't need to begin JavaDoc comments with "This class ..." or "This method ...". See the Method descriptions begin with a verb phrase section.

Some boilerplate does not need comments. For example, the "imports" section does not really need a comment. Also, some comments describe a little too much what is going on, and not the why (e.g. instead of "Sets formatting to break line at whole words ...", you could just have one comment "Create and format the JTextArea", unless there's a line you think will be particularly likely to forget why it's there.

Not a big issue, but plurals in English don't use apostrophe (e.g. menu's can be menus).

EDITED TO ADD:

exitFile() could be shortened while keeping the same functionality. Your options are only YES_OPTION and NO_OPTION, and there is duplicate code between them that can just execute regardless:

public void exitFile(boolean clear) {

    //  Prompts user with options to store file, not to store file or
    int options = JOptionPane.showConfirmDialog(
            txtArea, "Vil du lagre først?");

    //  If user acted on the YES option
    if (options == JOptionPane.YES_OPTION) {
        saveFile();
    }

    // And first acted on the 'Clear' menuItem
    if (clear) {
        txtArea.setText("");

    // And first acted on the 'Exit' menuItem
    } else {
        System.exit(0);
    }
}