How to generate a SHA-384 hash on Mac

SHA-384 turns up in particular places rather than everywhere. A TLS cipher suite named TLS_AES_256_GCM_SHA384. A certificate whose signature algorithm field reads ecdsa-with-SHA384. A script tag carrying an integrity attribute that begins sha384-. A security questionnaire that will not accept 256 bits. You rarely choose SHA-384 for yourself; something else chose it, and now you need one.

Producing it takes a few seconds. Type or paste your text into the Text tool and the SHA-384 row resolves as you type, under the SHA-2 group heading, one row below SHA-256. Drag a file into Files and the same digest comes out of a single pass over the disk. Either way you get 96 hexadecimal characters — 384 bits, 48 bytes, three ways of saying the same length.

The part nobody warns you about comes next: SHA-384 is built out of SHA-512 but cannot be obtained by trimming a SHA-512 digest, and the value somebody hands you is quite often base64 rather than hex. If you want to see one this minute, the SHA-384 generator on this site hashes whatever text you type into it, in a browser tab — a quick try, or a second opinion on a string somebody sent you. A file on disk is the Files tool's job, not a web page's.

What SHA-384 actually is

SHA-384 is SHA-512 with two changes and no others. Same compression function, same 1,024-bit message blocks, same 64-bit words, same 80 rounds. The first change is that it starts from a different set of eight initial values. The second is that it prints only the first 384 bits of the 512-bit state it finishes with, and discards the rest.

The second change is why the digest is shorter. The first is why you cannot take a shortcut. Because the starting state differs, every intermediate value differs, and the two digests of the same input have nothing in common but their length:

Both are genuine values you can reproduce for yourself — type the three letters into the Text tool and compare the SHA-384 and SHA-512 rows. They disagree from the first character, which is what a different initial state does.

Truncation is not merely cosmetic either. A full SHA-512 digest is the function's entire internal state at the end of the message, so if you know the digest of a secret followed by some data, and how many bytes went in, you can resume hashing from that state and produce a valid digest for a longer message without ever learning the secret. That is the length-extension trick. SHA-384 hands you three quarters of the state and keeps 128 bits back, so there is nothing to resume from. It is a side benefit rather than the reason the algorithm exists, but it is why some protocol designers reach for it.

Produce a SHA-384 on your Mac

Three steps, and the third one is the one people skip and regret. Rocket Hash computes all eight algorithms from the same input, so SHA-384 is not a mode you switch into — it is a row you read.

1. Choose Text or Files

   For a string, a key, a JSON blob or anything you can paste, use Text in the sidebar — it is free, and it recomputes every digest as you type, with the byte count underneath telling you how much it actually hashed. For something on disk, use Files and drag the file in. A string and a one-line file containing that string are different inputs, and the difference is usually a trailing newline.

2. Read the SHA-384 row

   Under the SHA-2 heading the rows run SHA-256, SHA-384, SHA-512. The digest is shown in a monospaced font with the middle replaced by an ellipsis, because 96 characters do not fit a window; clicking the row copies the whole value, not the shortened display. In the Files tool the Algorithm control in the toolbar decides which digest each file row shows, and the disclosure chevron at the end of a row opens every algorithm for that file at once.

3. Count the characters before you paste it

   96 is SHA-384. If what landed on your clipboard is 128 characters you copied the SHA-512 row, and if it is 64 you copied SHA-256 — both easy to do when three similar-looking rows sit next to each other. Whatever is going to consume the value will usually reject the wrong length rather than explain it, so the count is worth two seconds.

Where you will meet SHA-384

• TLS. Cipher suites pair AES-256 with SHA-384 for their handshake arithmetic, which is where names like TLS_AES_256_GCM_SHA384 come from.
• Certificates on elliptic curve chains. A P-384 key is conventionally signed over a SHA-384 digest, because matching the hash to the curve keeps the whole chain at one security level rather than leaving the weakest link somewhere surprising.
• Government and defense profiles. NSA guidance for protecting classified material specifies SHA-384 as the minimum, which is why it appears in procurement language far more often than in engineering practice.
• JSON Web Tokens. The ES384, HS384 and PS384 algorithms all hash with SHA-384.
• Subresource integrity. The integrity attribute on a stylesheet or script tag usually carries a SHA-384 — in base64, which the next section is about.

Notice what is absent from that list: download checksums. Installers, ISOs and release archives publish SHA-256 in the overwhelming majority of cases, so if your job is checking a download against a published value, SHA-384 is almost certainly not the algorithm you want. Use whichever one the publisher used; you are comparing against their value, and the two have to be the same function.

When the value is base64, not hex

Hexadecimal is a convention, not a property of the digest. A SHA-384 is 48 raw bytes, and the web platform prefers to write those bytes in base64 — so an integrity attribute looks nothing like the value you just copied, even when it describes the same file.

The base64 form of the SHA-384 of abc is ywB1P0WjXou1oD1pmsZQBycsMqsO3tFjGotgWkP/W+2AhgcroefMI1i67KE0yCWn. That is the same 48 bytes as the hex above, written differently. There is a pleasant accident here: 48 divides exactly by three, so a base64 SHA-384 never ends in an = sign, while a base64 SHA-256 is 44 characters and always ends in one.

Nothing prints both forms for you. The app's rows are hexadecimal, as almost everything that asks for a checksum expects, and the base64 in an integrity attribute is the same 48 bytes written in a denser alphabet — not a second digest, and not a conversion you can do by eye. So if yours is hex and theirs is base64, neither is wrong and neither needs fixing: you need the same value in the same encoding from one side or the other before a comparison means anything.

Getting SHA-384 and SHA-256 out of the same file

The awkward thing about SHA-384 is that it rarely arrives alone. A specification asks for 384 bits while the download page for the same artifact published a SHA-256, so you need two digests of one file and you need to be sure they describe the same bytes.

That is the shape the Files tool is built around. However many digests you want from a file, it is read exactly once — opening the chevron to see SHA-384 sitting beside SHA-256 costs no second trip over the disk, and leaves no gap in which the file could change between two separate runs. On a release artifact that matters: the two values provably describe the same bytes, rather than the same path at two different moments. Memory stays flat at roughly 16 MB whether the file is two kilobytes or a hundred gigabytes, so the size of the thing does not change the method.

The Text tool does the same thing live, which is the faster route for a key or a short string: every algorithm recomputes as you type, and Copy All puts the whole set on the clipboard in one go. Copying every hash at once covers what that produces.

Is SHA-384 stronger than SHA-256?

On paper, yes, and the arithmetic is simple: collision resistance tops out at half the digest length, which puts SHA-384 at 192 bits and SHA-256 at 128. In practice the comparison decides nothing, because all 128 of those bits are already out of reach — adding 64 more to a number nobody can get to does not change anyone's security. Choose on requirements and interoperability instead.

Speed does not settle it either. SHA-384 and SHA-512 run at the same rate as each other, which is the most direct evidence you will ever see that they are one function wearing two output lengths: the work is identical until the final truncation. Apple Silicon carries dedicated instructions for the 32-bit and the 64-bit members of the family alike, so none of them falls back to plain arithmetic — SHA-256 reaches roughly 2 GB/s there, which is already more than most drives can supply, and on a real file the disk is the limit whichever you pick.

So the honest answer is to use what the specification in front of you names, and to default to SHA-256 for anything you control, because every tool and every person reads it without asking. Which hash algorithm to use works through the cases where the default changes, and SHA-256 vs SHA-512 goes further into the 64-bit arithmetic that SHA-384 inherits.

Troubleshooting

The first 96 characters of my SHA-512 do not match the SHA-384

They never will, for any input. SHA-384 starts from different initial values, so it is a different function from the first block onward — the truncation is the last thing it does, not the only thing. Compute SHA-384 directly; there is no arithmetic that converts one digest into the other.

The value I was given has letters beyond f

Then it is not hexadecimal, and you are trying to compare two different encodings of possibly the same bytes. Capitals, +, / or a trailing = all mean base64. Ask whoever published it for the hexadecimal form — that is what every hashing tool prints by default, and it is the form you can put beside your own digest. Two encodings of the same 48 bytes look nothing alike, and no amount of staring will tell you whether they agree.

My digest does not match the one somebody else produced

Check that you both hashed the same bytes. The commonest cause by a distance is a trailing newline: a string typed into a text field has none, while the same line saved as a file has one, and a single extra byte changes every character of the digest. The byte count under the Text field is how you catch it — three letters should read 3 bytes, and a four means something came along for the ride. Why two tools give different hashes works through the rest of the causes, from line endings to text that was normalized on the way.

The certificate says SHA384 but its fingerprint is 64 characters

Those are two different fields describing two different things. The signature algorithm says which digest the issuing authority signed over when it created the certificate; the fingerprint is a digest somebody computed of the finished certificate so humans can compare it, and fingerprints are conventionally SHA-256 whatever the signature inside says. Neither is wrong and they are not meant to match.

I actually need SHA-512/256

That is a third truncated variant — SHA-512 cut to 256 bits, again with its own initial values — and it is neither SHA-384 nor SHA-256. It is rare enough that the app does not offer it among its eight algorithms, and the thing to avoid is substituting one of the eight for it: a SHA-256 is also 64 characters long and will not match. Check first that the specification really means SHA-512/256 rather than SHA-512, since the two are written confusingly close together.

Frequently asked questions

How many characters is a SHA-384 hash?

96 hexadecimal characters, which is 384 bits or 48 bytes. Written in base64 instead of hex it is 64 characters with no trailing = sign. Nothing else in common use produces 96 hex characters, so the length alone identifies it.

Can I get a SHA-384 by shortening a SHA-512 hash?

No. SHA-384 does truncate a 512-bit state down to 384 bits, but it also starts from a different set of initial values, so every step of the calculation differs. For the string abc, SHA-384 begins cb00753f and SHA-512 begins ddaf35a1 — they disagree from the first character. You have to compute SHA-384 directly.

Is SHA-384 more secure than SHA-256?

It carries a wider margin on paper, 192 bits against 128, but neither figure is within reach of any machine that will ever be built. Choose SHA-384 because a specification asks for it, not because you expect SHA-256 to fail. For work you control, SHA-256 is the better default purely because every tool reads it.

How do I get a SHA-384 checksum of a file on a Mac?

Drag the file into the Files tool and set the Algorithm control in the toolbar to SHA-384, or leave the control alone and open the chevron at the end of the file's row, which shows all eight digests from the same single read of the disk. The copy button on the row puts the full 96 characters on the clipboard rather than the shortened version shown on screen. Folders can be dropped in whole, and every file inside gets its own digest.

Why do TLS cipher suites use SHA-384?

To keep the whole handshake at one security level. A suite built on AES-256 and a P-384 key is undermined by a 256-bit hash, so the specification pairs them with SHA-384 instead. It is matching, not an upgrade — which is also why you see SHA-256 paired with AES-128.

Is SHA-384 part of SHA-2 or SHA-3?

SHA-2. The family is SHA-224, SHA-256, SHA-384, SHA-512 and the two SHA-512 truncations, all sharing one design. SHA-3 is an unrelated construction that happens to have been given consecutive numbering — see SHA-2 vs SHA-3 for what actually differs.

Is SHA-384 affected by length-extension attacks?

No, and that is one of its genuine advantages over SHA-512. A SHA-512 digest is the function's complete internal state, so an attacker who knows it can continue hashing from there without knowing the original input. SHA-384 withholds 128 bits of that state, so there is nothing to continue from.