The size of your browser window when you record decides how large the demo looks to everyone who watches it. Getting it right takes about ten seconds and it is the single easiest thing to get wrong.
A browser capture records the viewport, which is the area of the page inside your browser window. It is not your monitor, and it is not your screen resolution. Two people on completely different monitors who size their windows the same way produce identical captures.
A good default: record with your browser window at 1440 x 810. Slightly larger is fine. Much larger is where demos start looking small.
Do not trust the window size Windows reports, and do not trust the responsive toolbar in developer tools. Ask the page itself.
> prompt and press Enter:innerWidth + " x " + innerHeight
It prints something like "1440 x 810". That is exactly what will be captured. Resize the window, press the up arrow to bring the line back, press Enter again, and repeat until it reads what you want. Close developer tools before you record.
A finished demo is displayed at whatever size its container allows. Demo Maker Pro scales a demo down to fit, but never enlarges it past the size it was recorded at. That one rule explains both failure modes.
If you record much larger than the space the demo will be shown in, everything shrinks to fit and the text gets hard to read. A demo captured at 2560 pixels wide, shown in a 1000 pixel wide box on a web page, is displayed at about 40 per cent of its original size. The same demo captured at 1440 wide is displayed at about 70 per cent, and reads comfortably.
If you record much smaller than the screen someone views it on, the demo will not stretch to fill. It sits at its recorded size with space around it. That is far less damaging than the other direction, which is why erring smaller is the safer mistake.
A smaller window means more scrolling, which is normal and fine. One thing helps the result: when you follow a link to a new page and then need to scroll down before clicking, click something on the new page first, then scroll. That gives the demo a starting point to scroll from, so viewers see the page move rather than arriving part way down it.