Of course it's nested. Nesting has nothing to do with the way you format the code.

if (...)
{
    // some code
}
else if (...)
{
    // some code
}
else
{
    // some code
}

is exactly equivalent to

if (...)
{
    // some code
}
else
{
    if (...)
    {
        // some code
    }
    else
    {
        // some code
    }
}

There's no 'else if' keyword in Java, the effect is achieved purely by a formatting convention which stops long chains of nested elses from drifting right across the screen.

In case anybody needs persuading, here is the specification for an if statement: Java Language Specification section 14.9

You can indeed reduce the level of nesting significantly. However I leave it up to you whether you like it or not.

Your code currently has three levels of nesting, that's relatively okay. Use comments to make your code more readable instead. However you may adapt some of the following tricks.

Is still unassigned

String returnMessage = null;

// Something is empty
if (cipherFileRead.isEmpty() || freqFileRead.isEmpty()) {
    returnMessage = "Both files must be loaded and contain text. Decryption unsuccessful.";
}

// No description type given
if (returnMessage == null && freqChooser.getSelection() == null) {
    returnMessage = "Please select decryption type. Decryption unsuccessful";
}

// Decrypt
if (returnMessage == null) {
    // Select technique
    String decryptedText = null;
    if (nearestFreq.isSelected()) {
        decryptedText = decrypter.nearestFreq(cipherFileRead, freqFileRead);
    } else if (rankingFreq.isSelected()) {
        decryptedText = decrypter.byRanking(cipherFileRead, freqFileRead);
    }

    // Write decrypted text
    file.writeToFile(decryptedText, "output.txt");

    returnMessage = "Successfully decrypted to output.txt";
}

// Show return message
JOptionPane.showMessageDialog(null, returnMessage);

So the trick was to check whether returnMessage is still unassigned.

The disadvantage of this style is that it slows the program a bit because it makes it harder for the processor to guess the conditions correct for pipelining. This is called branch prediction and all processors do that.

But if it enhances readability, for example by reducing a really deep nesting, you may use it.

Return from method

However if this is a method I would definitely give the advice to use such a style, but then by using return like:

public String decryptFile() {
    // Something is empty
    if (cipherFileRead.isEmpty() || freqFileRead.isEmpty()) {
        return "Both files must be loaded and contain text. Decryption unsuccessful.";
    }

    // No description type given
    if (freqChooser.getSelection() == null) {
        return "Please select decryption type. Decryption unsuccessful";
    }

    // Decrypt
    // Select technique to use
    String decryptedText = null;
    if (nearestFreq.isSelected()) {
        decryptedText = decrypter.nearestFreq(cipherFileRead, freqFileRead);
    } else if (rankingFreq.isSelected()) {
        decryptedText = decrypter.byRanking(cipherFileRead, freqFileRead);
    } else {
        // Out of techniques?
        return "No decryption technique can be applied.";
        // Or if this must not happen due to context, use:
        // throw new AssertionError();
    }

    // Write decrypted text
    file.writeToFile(decryptedText, "output.txt");

    return "Successfully decrypted to output.txt";
}

And the caller will then do it like:

// Show return message
JOptionPane.showMessageDialog(null, decryptFile());

In this scenario, next to reducing the nesting, you also reduce the amount of time you spend in the code itself.

You should definitely pack this inside a method. It should not be the decision of the decryption where and how to display the return message. Instead return the message and let the caller decide how to use it.

Note that in practice you probably want to add some arguments to the method and so on. Also you may want to use exceptions instead of plain String messages, like IllegalArgumentException.