Selecting a vertical CRS only makes sense if its geoid model is in PROJ-data. To use geoid model files or any other grid file you have to enable "Use network". Initial computation that involves grid files may be slower, as it downloads part of the grid file.

When no vertical or 3D system is provided in source and target, PROJ does by default a 2D transformation. If you want a 3D transformation select "Promote to 3D". Horizontal values can be slightly different depending on the transformation.

To use your own "Main Database" in the "Advanced Options", it must be consistent with the current db schema. See that the "Auxiliary Databases" (can be multiple files) will make the processing slower, even if those CRSs are not used.

"Free Text" definion for a CRS works pretty well with WKT, PROJJSON or any other way to define a CRS accepted by PROJ.

"Input Coordinates" separator can be comma, semicolon, tab or space. The usage of comma as decimal separator works only with semicolon as coordinate separator. Hash (#) as first character consider the line a comment, not using that line. Each line can have different separators. Degrees are only accepted as decimal degrees. Not as DDMMSS.

The values for the input coordinates are X, Y, Z, t, with its meaning depending on the axes of the CRS. Only the first two are mandatory. Extra values per line will be ignored.

Most of the CRSs do not support an Epoch. Only some dependent systems that involve time dependent transformations.

Pay attention to the "Last Operation Summary". The pipeline operator can be very useful to understand the actual transformation applied.

Look how the URL is updated with your data. Just copy it if you want to share your transformation.

The transformation applied is usually equivalent to what you can do with cs2cs