One aspect of Mathematica probably deserves some emphasis in light of this question:

Sqrt[2]/4 autosimplifies back to 1/(2 Sqrt[2]).

Powers with the same base are combined; square roots are combined. The following sequence is like swimming upstream:

(-1 + Sqrt[3])/(2 Sqrt[2]) $\rightarrow$ Sqrt[2](-1 + Sqrt[3])/4 $\rightarrow$ (-Sqrt[2] + Sqrt[6])/4

If you don't stop the flow of evaluation, the second expression is swept downstream to the first automatically. The third expression is stable, if you can get there.

Luckily, there is a factor -1 + Sqrt[3], which can be multiplied term-by-term by Sqrt[2] to prevent Sqrt[2] from recombining with 4 (provided there is a way to do that before Sqrt[2]/4 autosimplifies). If you did not have such a factor, then there would be no way to keep the denominator rationalized.

That hopefully gives an idea of what one is up against in rationalizing the denominator. Other forms of simplification can also run against the flow of the autosimplification built into Mathematica.

Note that using Simplify[] or FullSimplify[] may or may not succeed in producing the desired form in each case. They try to produce an equivalent expression with a minimal number of leaves in its expression-tree. That's a distinct goal from rationalizing.

If formatting output is the main goal — by which I mean that you are not going to use the output as further input, but you are going to use it only for people to see and to read — then there are more ways. For instance, HoldForm[] or boxes.

The previous code presumed there were square-roots in the denominator to rationalize in the input. Instead of cluttering the thread with two long notebooks, I've converted this one to a simple link and posted the updated code below. One issue was that factor, which is an Association[] created by GroupBy[], may be missing a key. The solution to that issue is to replace factor[True] by Lookup[factor, True, {{1, 1}}] and factor[False] by Lookup[factor, False, {{1, 1}}]. The list {{1, 1}} is the result of FactorList[1] and essentially would set either the denominator or numerator to 1.

Another problem is that if there are no radical to rationalize, the denominator may well turn out to be 1. Since the old code always typeset a numerator and denominator, 2 would come out as 2 over 1, which seemed undesirable.

Link to old notebook: https://www.wolframcloud.com/obj/28ab7888-fa5a-40b0-822c-633f5a444300

Here's another version. I hadn't realized that FactorList rationalizes simple square-root factors in the denominator.

This does it:

In[33]:= Sin[\[Pi]/12] // RootReduce // ToRadicals

Out[33]= Sqrt[2 - Sqrt[3]]/2

Try (RawBoxes@rationalizeSqrtDenominatorBoxes[#, ExpandAll] & /@...

At first, I wasn't sure putting in optional processing for numerator and denominator was worth it. (I didn't put it in rationalizeSqrtDenominator[], for instance.) But here, where we're fighting the built-in ways WL processes formulas, it comes to the rescue. :)

Expand vs. ExpandAll: Expand[] expands a Plus[]/Times[] expression or elements of a list at the top level only and not inside other functions. ExpandAll[] goes all the way down the expression tree to find things to expand. (Note Sqrt[expr] evaluates to Power[expr, 1/2] and 1/Sqrt[expr] to Power[expr, -1/2].)

Expand[(x + 1)^2]
Expand[{(x + 1)^2, {(x + 1)^3}}]
Expand[{(x + 1)^2, Sqrt@{(x + 1)^3}}] (* not inside Power[] *)
ExpandAll[{(x + 1)^2, Sqrt@{(x + 1)^3}}] (* inside Power[] *)
(*
1 + 2 x + x^2
{1 + 2 x + x^2, {1 + 3 x + 3 x^2 + x^3}}
{1 + 2 x + x^2, {Sqrt[(1 + x)^3]}}
{1 + 2 x + x^2, {Sqrt[1 + 3 x + 3 x^2 + x^3]}}
*)

This result has been oversimplified.

Adding // Simplify to what you wrote gets for form that the OP desired.